Skip to content

Commit 715d94d

Browse files
advisory-database[bot]advisory-database[bot]
committed
Advisory Database Sync
1 parent 2017ca0 commit 715d94d

84 files changed

Lines changed: 1768 additions & 170 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎advisories/unreviewed/2026/02/GHSA-2chr-7vph-93pf/GHSA-2chr-7vph-93pf.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-2chr-7vph-93pf",
4-
"modified": "2026-02-14T18:30:15Z",
4+
"modified": "2026-03-17T21:31:41Z",
55
"published": "2026-02-14T18:30:14Z",
66
"aliases": [
77
"CVE-2026-23151"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix memory leak in set_ssp_complete\n\nFix memory leak in set_ssp_complete() where mgmt_pending_cmd structures\nare not freed after being removed from the pending list.\n\nCommit 302a1f674c00 (\"Bluetooth: MGMT: Fix possible UAFs\") replaced\nmgmt_pending_foreach() calls with individual command handling but missed\nadding mgmt_pending_free() calls in both error and success paths of\nset_ssp_complete(). Other completion functions like set_le_complete()\nwere fixed correctly in the same commit.\n\nThis causes a memory leak of the mgmt_pending_cmd structure and its\nassociated parameter data for each SSP command that completes.\n\nAdd the missing mgmt_pending_free(cmd) calls in both code paths to fix\nthe memory leak. Also fix the same issue in set_advertising_complete().",
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-401"
38+
],
39+
"severity": "MODERATE",
3340
"github_reviewed": false,
3441
"github_reviewed_at": null,
3542
"nvd_published_at": "2026-02-14T16:15:55Z"

‎advisories/unreviewed/2026/02/GHSA-2j2f-9hjh-v2xm/GHSA-2j2f-9hjh-v2xm.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-2j2f-9hjh-v2xm",
4-
"modified": "2026-02-14T18:30:15Z",
4+
"modified": "2026-03-17T21:31:41Z",
55
"published": "2026-02-14T18:30:15Z",
66
"aliases": [
77
"CVE-2026-23150"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().\n\nsyzbot reported various memory leaks related to NFC, struct\nnfc_llcp_sock, sk_buff, nfc_dev, etc. [0]\n\nThe leading log hinted that nfc_llcp_send_ui_frame() failed\nto allocate skb due to sock_error(sk) being -ENXIO.\n\nENXIO is set by nfc_llcp_socket_release() when struct\nnfc_llcp_local is destroyed by local_cleanup().\n\nThe problem is that there is no synchronisation between\nnfc_llcp_send_ui_frame() and local_cleanup(), and skb\ncould be put into local->tx_queue after it was purged in\nlocal_cleanup():\n\n CPU1 CPU2\n ---- ----\n nfc_llcp_send_ui_frame() local_cleanup()\n |- do { '\n |- pdu = nfc_alloc_send_skb(..., &err)\n | .\n | |- nfc_llcp_socket_release(local, false, ENXIO);\n | |- skb_queue_purge(&local->tx_queue); |\n | ' |\n |- skb_queue_tail(&local->tx_queue, pdu); |\n ... |\n |- pdu = nfc_alloc_send_skb(..., &err) |\n ^._________________________________.'\n\nlocal_cleanup() is called for struct nfc_llcp_local only\nafter nfc_llcp_remove_local() unlinks it from llcp_devices.\n\nIf we hold local->tx_queue.lock then, we can synchronise\nthe thread and nfc_llcp_send_ui_frame().\n\nLet's do that and check list_empty(&local->list) before\nqueuing skb to local->tx_queue in nfc_llcp_send_ui_frame().\n\n[0]:\n[ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)\n[ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nBUG: memory leak\nunreferenced object 0xffff8881272f6800 (size 1024):\n comm \"syz.0.17\", pid 6096, jiffies 4294942766\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............\n backtrace (crc da58d84d):\n kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n slab_post_alloc_hook mm/slub.c:4979 [inline]\n slab_alloc_node mm/slub.c:5284 [inline]\n __do_kmalloc_node mm/slub.c:5645 [inline]\n __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658\n kmalloc_noprof include/linux/slab.h:961 [inline]\n sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239\n sk_alloc+0x36/0x360 net/core/sock.c:2295\n nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979\n llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044\n nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31\n __sock_create+0x1a9/0x340 net/socket.c:1605\n sock_create net/socket.c:1663 [inline]\n __sys_socket_create net/socket.c:1700 [inline]\n __sys_socket+0xb9/0x1a0 net/socket.c:1747\n __do_sys_socket net/socket.c:1761 [inline]\n __se_sys_socket net/socket.c:1759 [inline]\n __x64_sys_socket+0x1b/0x30 net/socket.c:1759\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nBUG: memory leak\nunreferenced object 0xffff88810fbd9800 (size 240):\n comm \"syz.0.17\", pid 6096, jiffies 4294942850\n hex dump (first 32 bytes):\n 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h.......\n 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'....\n backtrace (crc 6cc652b1):\n kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]\n slab_post_alloc_hook mm/slub.c:4979 [inline]\n slab_alloc_node mm/slub.c:5284 [inline]\n kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336\n __alloc_skb+0x203/0x240 net/core/skbuff.c:660\n alloc_skb include/linux/skbuff.h:1383 [inline]\n alloc_skb_with_frags+0x69/0x3f0 net/core/sk\n---truncated---",
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
{
@@ -44,8 +49,10 @@
4449
}
4550
],
4651
"database_specific": {
47-
"cwe_ids": [],
48-
"severity": null,
52+
"cwe_ids": [
53+
"CWE-401"
54+
],
55+
"severity": "MODERATE",
4956
"github_reviewed": false,
5057
"github_reviewed_at": null,
5158
"nvd_published_at": "2026-02-14T16:15:55Z"

‎advisories/unreviewed/2026/02/GHSA-2j82-cf92-x9qh/GHSA-2j82-cf92-x9qh.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-2j82-cf92-x9qh",
4-
"modified": "2026-02-06T18:30:30Z",
4+
"modified": "2026-03-17T21:31:40Z",
55
"published": "2026-02-04T18:30:43Z",
66
"aliases": [
77
"CVE-2026-23084"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list\n\nWhen the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is\nset to false, the driver may request the PMAC_ID from the firmware of the\nnetwork card, and this function will store that PMAC_ID at the provided\naddress pmac_id. This is the contract of this function.\n\nHowever, there is a location within the driver where both\npmac_id_valid == false and pmac_id == NULL are being passed. This could\nresult in dereferencing a NULL pointer.\n\nTo resolve this issue, it is necessary to pass the address of a stub\nvariable to the function.",
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
{
@@ -44,8 +49,10 @@
4449
}
4550
],
4651
"database_specific": {
47-
"cwe_ids": [],
48-
"severity": null,
52+
"cwe_ids": [
53+
"CWE-476"
54+
],
55+
"severity": "MODERATE",
4956
"github_reviewed": false,
5057
"github_reviewed_at": null,
5158
"nvd_published_at": "2026-02-04T17:16:19Z"

‎advisories/unreviewed/2026/02/GHSA-2rcf-99h2-99hm/GHSA-2rcf-99h2-99hm.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-2rcf-99h2-99hm",
4-
"modified": "2026-02-06T18:30:30Z",
4+
"modified": "2026-03-17T21:31:40Z",
55
"published": "2026-02-04T18:30:44Z",
66
"aliases": [
77
"CVE-2026-23090"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nslimbus: core: fix device reference leak on report present\n\nSlimbus devices can be allocated dynamically upon reception of\nreport-present messages.\n\nMake sure to drop the reference taken when looking up already registered\ndevices.\n\nNote that this requires taking an extra reference in case the device has\nnot yet been registered and has to be allocated.",
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
{
@@ -45,7 +50,7 @@
4550
],
4651
"database_specific": {
4752
"cwe_ids": [],
48-
"severity": null,
53+
"severity": "MODERATE",
4954
"github_reviewed": false,
5055
"github_reviewed_at": null,
5156
"nvd_published_at": "2026-02-04T17:16:19Z"

‎advisories/unreviewed/2026/02/GHSA-372h-fwqg-rp6x/GHSA-372h-fwqg-rp6x.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-372h-fwqg-rp6x",
4-
"modified": "2026-02-14T18:30:14Z",
4+
"modified": "2026-03-17T21:31:41Z",
55
"published": "2026-02-14T18:30:14Z",
66
"aliases": [
77
"CVE-2026-23143"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix misalignment bug in struct virtnet_info\n\nUse the new TRAILING_OVERLAP() helper to fix a misalignment bug\nalong with the following warning:\n\ndrivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]\n\nThis helper creates a union between a flexible-array member (FAM)\nand a set of members that would otherwise follow it (in this case\n`u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This\noverlays the trailing members (rss_hash_key_data) onto the FAM\n(hash_key_data) while keeping the FAM and the start of MEMBERS aligned.\nThe static_assert() ensures this alignment remains.\n\nNotice that due to tail padding in flexible `struct\nvirtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`\n(at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at\noffset 84 in struct virtnet_info) are misaligned by one byte. See\nbelow:\n\nstruct virtio_net_rss_config_trailer {\n __le16 max_tx_vq; /* 0 2 */\n __u8 hash_key_length; /* 2 1 */\n __u8 hash_key_data[]; /* 3 0 */\n\n /* size: 4, cachelines: 1, members: 3 */\n /* padding: 1 */\n /* last cacheline: 4 bytes */\n};\n\nstruct virtnet_info {\n...\n struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */\n\n /* XXX last struct has 1 byte of padding */\n\n u8 rss_hash_key_data[40]; /* 84 40 */\n...\n /* size: 832, cachelines: 13, members: 48 */\n /* sum members: 801, holes: 8, sum holes: 31 */\n /* paddings: 2, sum paddings: 5 */\n};\n\nAfter changes, those members are correctly aligned at offset 795:\n\nstruct virtnet_info {\n...\n union {\n struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */\n struct {\n unsigned char __offset_to_hash_key_data[3]; /* 792 3 */\n u8 rss_hash_key_data[40]; /* 795 40 */\n }; /* 792 43 */\n }; /* 792 44 */\n...\n /* size: 840, cachelines: 14, members: 47 */\n /* sum members: 801, holes: 8, sum holes: 35 */\n /* padding: 4 */\n /* paddings: 1, sum paddings: 4 */\n /* last cacheline: 8 bytes */\n};\n\nAs a result, the RSS key passed to the device is shifted by 1\nbyte: the last byte is cut off, and instead a (possibly\nuninitialized) byte is added at the beginning.\n\nAs a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also\nmoved to the end, since it seems those three members should stick\naround together. :)",
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": "2026-02-14T16:15:54Z"

‎advisories/unreviewed/2026/02/GHSA-3gp7-mv7f-66rh/GHSA-3gp7-mv7f-66rh.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-3gp7-mv7f-66rh",
4-
"modified": "2026-02-04T18:30:44Z",
4+
"modified": "2026-03-17T21:31:40Z",
55
"published": "2026-02-04T18:30:44Z",
66
"aliases": [
77
"CVE-2026-23088"
88
],
99
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix crash on synthetic stacktrace field usage\n\nWhen creating a synthetic event based on an existing synthetic event that\nhad a stacktrace field and the new synthetic event used that field a\nkernel crash occurred:\n\n ~# cd /sys/kernel/tracing\n ~# echo 's:stack unsigned long stack[];' > dynamic_events\n ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger\n ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/trigger\n\nThe above creates a synthetic event that takes a stacktrace when a task\nschedules out in a non-running state and passes that stacktrace to the\nsched_switch event when that task schedules back in. It triggers the\n\"stack\" synthetic event that has a stacktrace as its field (called \"stack\").\n\n ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events\n ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger\n ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/trigger\n\nThe above makes another synthetic event called \"syscall_stack\" that\nattaches the first synthetic event (stack) to the sys_exit trace event and\nrecords the stacktrace from the stack event with the id of the system call\nthat is exiting.\n\nWhen enabling this event (or using it in a historgram):\n\n ~# echo 1 > events/synthetic/syscall_stack/enable\n\nProduces a kernel crash!\n\n BUG: unable to handle page fault for address: 0000000000400010\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP PTI\n CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:trace_event_raw_event_synth+0x90/0x380\n Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f\n RSP: 0018:ffffd2670388f958 EFLAGS: 00010202\n RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0\n RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50\n R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010\n R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90\n FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0\n Call Trace:\n <TASK>\n ? __tracing_map_insert+0x208/0x3a0\n action_trace+0x67/0x70\n event_hist_trigger+0x633/0x6d0\n event_triggers_call+0x82/0x130\n trace_event_buffer_commit+0x19d/0x250\n trace_event_raw_event_sys_exit+0x62/0xb0\n syscall_exit_work+0x9d/0x140\n do_syscall_64+0x20a/0x2f0\n ? trace_event_raw_event_sched_switch+0x12b/0x170\n ? save_fpregs_to_fpstate+0x3e/0x90\n ? _raw_spin_unlock+0xe/0x30\n ? finish_task_switch.isra.0+0x97/0x2c0\n ? __rseq_handle_notify_resume+0xad/0x4c0\n ? __schedule+0x4b8/0xd00\n ? restore_fpregs_from_fpstate+0x3c/0x90\n ? switch_fpu_return+0x5b/0xe0\n ? do_syscall_64+0x1ef/0x2f0\n ? do_fault+0x2e9/0x540\n ? __handle_mm_fault+0x7d1/0xf70\n ? count_memcg_events+0x167/0x1d0\n ? handle_mm_fault+0x1d7/0x2e0\n ? do_user_addr_fault+0x2c3/0x7f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reason is that the stacktrace field is not labeled as such, and is\ntreated as a normal field and not as a dynamic event that it is.\n\nIn trace_event_raw_event_synth() the event is field is still treated as a\ndynamic array, but the retrieval of the data is considered a normal field,\nand the reference is just the meta data:\n\n// Meta data is retrieved instead of a dynamic array\n---truncated---",
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
{
@@ -32,8 +37,10 @@
3237
}
3338
],
3439
"database_specific": {
35-
"cwe_ids": [],
36-
"severity": null,
40+
"cwe_ids": [
41+
"CWE-476"
42+
],
43+
"severity": "MODERATE",
3744
"github_reviewed": false,
3845
"github_reviewed_at": null,
3946
"nvd_published_at": "2026-02-04T17:16:19Z"

0 commit comments

Comments
 (0)