Skip to content

Commit e1312db

Browse files
Advisory Database Sync
1 parent 8670d2c commit e1312db

File tree

26 files changed

+359
-56
lines changed

26 files changed

+359
-56
lines changed

advisories/unreviewed/2023/12/GHSA-27q9-h529-q4g3/GHSA-27q9-h529-q4g3.json

Lines changed: 13 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-27q9-h529-q4g3",
4-
"modified": "2025-11-18T21:32:28Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2023-12-24T09:30:19Z",
66
"aliases": [
77
"CVE-2023-51767"
@@ -111,6 +111,10 @@
111111
"type": "WEB",
112112
"url": "http://www.openwall.com/lists/oss-security/2025/09/27/3"
113113
},
114+
{
115+
"type": "WEB",
116+
"url": "http://www.openwall.com/lists/oss-security/2025/09/27/4"
117+
},
114118
{
115119
"type": "WEB",
116120
"url": "http://www.openwall.com/lists/oss-security/2025/09/27/5"
@@ -123,6 +127,14 @@
123127
"type": "WEB",
124128
"url": "http://www.openwall.com/lists/oss-security/2025/09/27/7"
125129
},
130+
{
131+
"type": "WEB",
132+
"url": "http://www.openwall.com/lists/oss-security/2025/09/28/7"
133+
},
134+
{
135+
"type": "WEB",
136+
"url": "http://www.openwall.com/lists/oss-security/2025/09/29/1"
137+
},
126138
{
127139
"type": "WEB",
128140
"url": "http://www.openwall.com/lists/oss-security/2025/09/29/4"

advisories/unreviewed/2025/08/GHSA-4x9v-h3r3-c3mf/GHSA-4x9v-h3r3-c3mf.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-4x9v-h3r3-c3mf",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38523"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix the smbd_response slab to allow usercopy\n\nThe handling of received data in the smbdirect client code involves using\ncopy_to_iter() to copy data from the smbd_reponse struct's packet trailer\nto a folioq buffer provided by netfslib that encapsulates a chunk of\npagecache.\n\nIf, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks\nthen performed in copy_to_iter() oopsing with something like the following:\n\n CIFS: Attempting to mount //172.31.9.1/test\n CIFS: VFS: RDMA transport established\n usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)!\n ------------[ cut here ]------------\n kernel BUG at mm/usercopy.c:102!\n ...\n RIP: 0010:usercopy_abort+0x6c/0x80\n ...\n Call Trace:\n <TASK>\n __check_heap_object+0xe3/0x120\n __check_object_size+0x4dc/0x6d0\n smbd_recv+0x77f/0xfe0 [cifs]\n cifs_readv_from_socket+0x276/0x8f0 [cifs]\n cifs_read_from_socket+0xcd/0x120 [cifs]\n cifs_demultiplex_thread+0x7e9/0x2d50 [cifs]\n kthread+0x396/0x830\n ret_from_fork+0x2b8/0x3b0\n ret_from_fork_asm+0x1a/0x30\n\nThe problem is that the smbd_response slab's packet field isn't marked as\nbeing permitted for usercopy.\n\nFix this by passing parameters to kmem_slab_create() to indicate that\ncopy_to_iter() is permitted from the packet region of the smbd_response\nslab objects, less the header space.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -28,8 +33,10 @@
2833
}
2934
],
3035
"database_specific": {
31-
"cwe_ids": [],
32-
"severity": null,
36+
"cwe_ids": [
37+
"CWE-1188"
38+
],
39+
"severity": "MODERATE",
3340
"github_reviewed": false,
3441
"github_reviewed_at": null,
3542
"nvd_published_at": "2025-08-16T12:15:27Z"

advisories/unreviewed/2025/08/GHSA-569j-76w5-38vw/GHSA-569j-76w5-38vw.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-569j-76w5-38vw",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38524"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix recv-recv race of completed call\n\nIf a call receives an event (such as incoming data), the call gets placed\non the socket's queue and a thread in recvmsg can be awakened to go and\nprocess it. Once the thread has picked up the call off of the queue,\nfurther events will cause it to be requeued, and once the socket lock is\ndropped (recvmsg uses call->user_mutex to allow the socket to be used in\nparallel), a second thread can come in and its recvmsg can pop the call off\nthe socket queue again.\n\nIn such a case, the first thread will be receiving stuff from the call and\nthe second thread will be blocked on call->user_mutex. The first thread\ncan, at this point, process both the event that it picked call for and the\nevent that the second thread picked the call for and may see the call\nterminate - in which case the call will be \"released\", decoupling the call\nfrom the user call ID assigned to it (RXRPC_USER_CALL_ID in the control\nmessage).\n\nThe first thread will return okay, but then the second thread will wake up\nholding the user_mutex and, if it sees that the call has been released by\nthe first thread, it will BUG thusly:\n\n\tkernel BUG at net/rxrpc/recvmsg.c:474!\n\nFix this by just dequeuing the call and ignoring it if it is seen to be\nalready released. We can't tell userspace about it anyway as the user call\nID has become stale.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -32,8 +37,10 @@
3237
}
3338
],
3439
"database_specific": {
35-
"cwe_ids": [],
36-
"severity": null,
40+
"cwe_ids": [
41+
"CWE-362"
42+
],
43+
"severity": "MODERATE",
3744
"github_reviewed": false,
3845
"github_reviewed_at": null,
3946
"nvd_published_at": "2025-08-16T12:15:27Z"

advisories/unreviewed/2025/08/GHSA-59vp-pw3x-2g3w/GHSA-59vp-pw3x-2g3w.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-59vp-pw3x-2g3w",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38511"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/pf: Clear all LMTT pages on alloc\n\nOur LMEM buffer objects are not cleared by default on alloc\nand during VF provisioning we only setup LMTT PTEs for the\nactually provisioned LMEM range. But beyond that valid range\nwe might leave some stale data that could either point to some\nother VFs allocations or even to the PF pages.\n\nExplicitly clear all new LMTT page to avoid the risk that a\nmalicious VF would try to exploit that gap.\n\nWhile around add asserts to catch any undesired PTE overwrites\nand low-level debug traces to track LMTT PT life-cycle.\n\n(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -29,7 +34,7 @@
2934
],
3035
"database_specific": {
3136
"cwe_ids": [],
32-
"severity": null,
37+
"severity": "MODERATE",
3338
"github_reviewed": false,
3439
"github_reviewed_at": null,
3540
"nvd_published_at": "2025-08-16T11:15:44Z"

advisories/unreviewed/2025/08/GHSA-6x2c-jc67-wp74/GHSA-6x2c-jc67-wp74.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-6x2c-jc67-wp74",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38525"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix irq-disabled in local_bh_enable()\n\nThe rxrpc_assess_MTU_size() function calls down into the IP layer to find\nout the MTU size for a route. When accepting an incoming call, this is\ncalled from rxrpc_new_incoming_call() which holds interrupts disabled\nacross the code that calls down to it. Unfortunately, the IP layer uses\nlocal_bh_enable() which, config dependent, throws a warning if IRQs are\nenabled:\n\nWARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0\n...\nRIP: 0010:__local_bh_enable_ip+0x43/0xd0\n...\nCall Trace:\n <TASK>\n rt_cache_route+0x7e/0xa0\n rt_set_nexthop.isra.0+0x3b3/0x3f0\n __mkroute_output+0x43a/0x460\n ip_route_output_key_hash+0xf7/0x140\n ip_route_output_flow+0x1b/0x90\n rxrpc_assess_MTU_size.isra.0+0x2a0/0x590\n rxrpc_new_incoming_peer+0x46/0x120\n rxrpc_alloc_incoming_call+0x1b1/0x400\n rxrpc_new_incoming_call+0x1da/0x5e0\n rxrpc_input_packet+0x827/0x900\n rxrpc_io_thread+0x403/0xb60\n kthread+0x2f7/0x310\n ret_from_fork+0x2a/0x230\n ret_from_fork_asm+0x1a/0x30\n...\nhardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50\nhardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70\nsoftirqs last enabled at (0): copy_process+0xc61/0x2730\nsoftirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90\n\nFix this by moving the call to rxrpc_assess_MTU_size() out of\nrxrpc_init_peer() and further up the stack where it can be done without\ninterrupts disabled.\n\nIt shouldn't be a problem for rxrpc_new_incoming_call() to do it after the\nlocks are dropped as pmtud is going to be performed by the I/O thread - and\nwe're in the I/O thread at this point.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -25,7 +30,7 @@
2530
],
2631
"database_specific": {
2732
"cwe_ids": [],
28-
"severity": null,
33+
"severity": "MODERATE",
2934
"github_reviewed": false,
3035
"github_reviewed_at": null,
3136
"nvd_published_at": "2025-08-16T12:15:27Z"

advisories/unreviewed/2025/08/GHSA-864c-jv4g-gp7q/GHSA-864c-jv4g-gp7q.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-864c-jv4g-gp7q",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38517"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users()\n\nalloc_tag_top_users() attempts to lock alloc_tag_cttype->mod_lock even\nwhen the alloc_tag_cttype is not allocated because:\n\n 1) alloc tagging is disabled because mem profiling is disabled\n (!alloc_tag_cttype)\n 2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype)\n 3) alloc tagging is enabled, but failed initialization\n (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype))\n\nIn all cases, alloc_tag_cttype is not allocated, and therefore\nalloc_tag_top_users() should not attempt to acquire the semaphore.\n\nThis leads to a crash on memory allocation failure by attempting to\nacquire a non-existent semaphore:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]\n CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.0-rc2 #1 VOLUNTARY\n Tainted: [D]=DIE\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:down_read_trylock+0xaa/0x3b0\n Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff\n RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016\n RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000\n RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070\n RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1\n R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37\n R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000\n FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0\n Call Trace:\n <TASK>\n codetag_trylock_module_list+0xd/0x20\n alloc_tag_top_users+0x369/0x4b0\n __show_mem+0x1cd/0x6e0\n warn_alloc+0x2b1/0x390\n __alloc_frozen_pages_noprof+0x12b9/0x21a0\n alloc_pages_mpol+0x135/0x3e0\n alloc_slab_page+0x82/0xe0\n new_slab+0x212/0x240\n ___slab_alloc+0x82a/0xe00\n </TASK>\n\nAs David Wang points out, this issue became easier to trigger after commit\n780138b12381 (\"alloc_tag: check mem_profiling_support in alloc_tag_init\").\n\nBefore the commit, the issue occurred only when it failed to allocate and\ninitialize alloc_tag_cttype or if a memory allocation fails before\nalloc_tag_init() is called. After the commit, it can be easily triggered\nwhen memory profiling is compiled but disabled at boot.\n\nTo properly determine whether alloc_tag_init() has been called and its\ndata structures initialized, verify that alloc_tag_cttype is a valid\npointer before acquiring the semaphore. If the variable is NULL or an\nerror value, it has not been properly initialized. In such a case, just\nskip and do not attempt to acquire the semaphore.\n\n[[email protected]: v3]",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -28,8 +33,10 @@
2833
}
2934
],
3035
"database_specific": {
31-
"cwe_ids": [],
32-
"severity": null,
36+
"cwe_ids": [
37+
"CWE-476"
38+
],
39+
"severity": "MODERATE",
3340
"github_reviewed": false,
3441
"github_reviewed_at": null,
3542
"nvd_published_at": "2025-08-16T11:15:44Z"

advisories/unreviewed/2025/08/GHSA-8mqg-35g3-7pvm/GHSA-8mqg-35g3-7pvm.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-8mqg-35g3-7pvm",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38522"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/ext: Prevent update_locked_rq() calls with NULL rq\n\nAvoid invoking update_locked_rq() when the runqueue (rq) pointer is NULL\nin the SCX_CALL_OP and SCX_CALL_OP_RET macros.\n\nPreviously, calling update_locked_rq(NULL) with preemption enabled could\ntrigger the following warning:\n\n BUG: using __this_cpu_write() in preemptible [00000000]\n\nThis happens because __this_cpu_write() is unsafe to use in preemptible\ncontext.\n\nrq is NULL when an ops invoked from an unlocked context. In such cases, we\ndon't need to store any rq, since the value should already be NULL\n(unlocked). Ensure that update_locked_rq() is only called when rq is\nnon-NULL, preventing calling __this_cpu_write() on preemptible context.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -24,8 +29,10 @@
2429
}
2530
],
2631
"database_specific": {
27-
"cwe_ids": [],
28-
"severity": null,
32+
"cwe_ids": [
33+
"CWE-476"
34+
],
35+
"severity": "MODERATE",
2936
"github_reviewed": false,
3037
"github_reviewed_at": null,
3138
"nvd_published_at": "2025-08-16T12:15:27Z"

advisories/unreviewed/2025/08/GHSA-964p-9vqv-9rhv/GHSA-964p-9vqv-9rhv.json

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-964p-9vqv-9rhv",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38518"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Disable INVLPGB on Zen2\n\nAMD Cyan Skillfish (Family 17h, Model 47h, Stepping 0h) has an issue\nthat causes system oopses and panics when performing TLB flush using\nINVLPGB.\n\nHowever, the problem is that that machine has misconfigured CPUID and\nshould not report the INVLPGB bit in the first place. So zap the\nkernel's representation of the flag so that nothing gets confused.\n\n [ bp: Massage. ]",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -25,7 +30,7 @@
2530
],
2631
"database_specific": {
2732
"cwe_ids": [],
28-
"severity": null,
33+
"severity": "MODERATE",
2934
"github_reviewed": false,
3035
"github_reviewed_at": null,
3136
"nvd_published_at": "2025-08-16T11:15:45Z"

advisories/unreviewed/2025/08/GHSA-mvcj-x699-wrp4/GHSA-mvcj-x699-wrp4.json

Lines changed: 11 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-mvcj-x699-wrp4",
4-
"modified": "2025-08-16T12:30:32Z",
4+
"modified": "2025-11-19T00:31:23Z",
55
"published": "2025-08-16T12:30:32Z",
66
"aliases": [
77
"CVE-2025-38519"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon: fix divide by zero in damon_get_intervals_score()\n\nThe current implementation allows having zero size regions with no special\nreasons, but damon_get_intervals_score() gets crashed by divide by zero\nwhen the region size is zero.\n\n [ 29.403950] Oops: divide error: 0000 [#1] SMP NOPTI\n\nThis patch fixes the bug, but does not disallow zero size regions to keep\nthe backward compatibility since disallowing zero size regions might be a\nbreaking change for some users.\n\nIn addition, the same crash can happen when intervals_goal.access_bp is\nzero so this should be fixed in stable trees as well.",
10-
"severity": [],
10+
"severity": [
11+
{
12+
"type": "CVSS_V3",
13+
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
14+
}
15+
],
1116
"affected": [],
1217
"references": [
1318
{
@@ -24,8 +29,10 @@
2429
}
2530
],
2631
"database_specific": {
27-
"cwe_ids": [],
28-
"severity": null,
32+
"cwe_ids": [
33+
"CWE-369"
34+
],
35+
"severity": "MODERATE",
2936
"github_reviewed": false,
3037
"github_reviewed_at": null,
3138
"nvd_published_at": "2025-08-16T11:15:45Z"

advisories/unreviewed/2025/11/GHSA-47cr-8w72-ggmc/GHSA-47cr-8w72-ggmc.json

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-47cr-8w72-ggmc",
4-
"modified": "2025-11-18T18:32:54Z",
4+
"modified": "2025-11-19T00:31:24Z",
55
"published": "2025-11-18T18:32:54Z",
66
"aliases": [
77
"CVE-2025-58034"
@@ -22,6 +22,10 @@
2222
{
2323
"type": "WEB",
2424
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-513"
25+
},
26+
{
27+
"type": "WEB",
28+
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-58034"
2529
}
2630
],
2731
"database_specific": {

0 commit comments

Comments
 (0)