CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
721 vulnerabilities reference this CWE, most recent first.
GHSA-C6P9-MW2R-7MC4
Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-09-24 21:30In the Linux kernel, the following vulnerability has been resolved:
cfg80211: fix management registrations locking
The management registrations locking was broken, the list was locked for each wdev, but cfg80211_mgmt_registrations_update() iterated it without holding all the correct spinlocks, causing list corruption.
Rather than trying to fix it with fine-grained locking, just move the lock to the wiphy/rdev (still need the list on each wdev), we already need to hold the wdev lock to change it, so there's no contention on the lock in any case. This trivially fixes the bug since we hold one wdev's lock already, and now will hold the lock that protects all lists.
{
"affected": [],
"aliases": [
"CVE-2021-47494"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T09:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncfg80211: fix management registrations locking\n\nThe management registrations locking was broken, the list was\nlocked for each wdev, but cfg80211_mgmt_registrations_update()\niterated it without holding all the correct spinlocks, causing\nlist corruption.\n\nRather than trying to fix it with fine-grained locking, just\nmove the lock to the wiphy/rdev (still need the list on each\nwdev), we already need to hold the wdev lock to change it, so\nthere\u0027s no contention on the lock in any case. This trivially\nfixes the bug since we hold one wdev\u0027s lock already, and now\nwill hold the lock that protects all lists.",
"id": "GHSA-c6p9-mw2r-7mc4",
"modified": "2025-09-24T21:30:30Z",
"published": "2024-05-22T09:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47494"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09b1d5dc6ce1c9151777f6c4e128a59457704c97"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c897f39b71fe68f90599f6a45b5f7bf5618420e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c22227e39c7a0b4dab55617ee8d34d171fab8d4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C6Q3-XGG3-276C
Vulnerability from github – Published: 2024-03-04 18:30 – Updated: 2025-02-03 15:31In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix locking in ieee80211_start_ap error path
We need to hold the local->mtx to release the channel context, as even encoded by the lockdep_assert_held() there. Fix it.
{
"affected": [],
"aliases": [
"CVE-2021-47091"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-04T18:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix locking in ieee80211_start_ap error path\n\nWe need to hold the local-\u003emtx to release the channel context,\nas even encoded by the lockdep_assert_held() there. Fix it.",
"id": "GHSA-c6q3-xgg3-276c",
"modified": "2025-02-03T15:31:59Z",
"published": "2024-03-04T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47091"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87a270625a89fc841f1a7e21aae6176543d8385c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac61b9c6c0549aaeb98194cf429d93c41bfe5f79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1d1ec4db5f7264cfc21993e59e8f2dcecf4b44f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C7GR-CRGH-PWCP
Vulnerability from github – Published: 2025-03-17 18:31 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
tty: fix deadlock caused by calling printk() under tty_port->lock
pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner);
As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided.
Syzbot reported the following lockdep error:
====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...]
-> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49441"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:20Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix deadlock caused by calling printk() under tty_port-\u003elock\n\npty_write() invokes kmalloc() which may invoke a normal printk() to print\nfailure message. This can cause a deadlock in the scenario reported by\nsyz-bot below:\n\n CPU0 CPU1 CPU2\n ---- ---- ----\n lock(console_owner);\n lock(\u0026port_lock_key);\n lock(\u0026port-\u003elock);\n lock(\u0026port_lock_key);\n lock(\u0026port-\u003elock);\n lock(console_owner);\n\nAs commit dbdda842fe96 (\"printk: Add console owner and waiter logic to\nload balance console writes\") said, such deadlock can be prevented by\nusing printk_deferred() in kmalloc() (which is invoked in the section\nguarded by the port-\u003elock). But there are too many printk() on the\nkmalloc() path, and kmalloc() can be called from anywhere, so changing\nprintk() to printk_deferred() is too complicated and inelegant.\n\nTherefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so\nthat printk() will not be called, and this deadlock problem can be\navoided.\n\nSyzbot reported the following lockdep error:\n\n======================================================\nWARNING: possible circular locking dependency detected\n5.4.143-00237-g08ccc19a-dirty #10 Not tainted\n------------------------------------------------------\nsyz-executor.4/29420 is trying to acquire lock:\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023\n\nbut task is already holding lock:\nffff8880119c9158 (\u0026port-\u003elock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #2 (\u0026port-\u003elock){-.-.}-{2:2}:\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n tty_port_tty_get drivers/tty/tty_port.c:288 [inline] \t\t\u003c-- lock(\u0026port-\u003elock);\n tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47\n serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767\n serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854\n serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] \t\u003c-- lock(\u0026port_lock_key);\n serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870\n serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126\n __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156\n [...]\n\n-\u003e #1 (\u0026port_lock_key){-.-.}-{2:2}:\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198\n\t\t\t\t\t\t\t\t\t\t\u003c-- lock(\u0026port_lock_key);\n call_console_drivers kernel/printk/printk.c:1819 [inline]\n console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504\n vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024\t\t\t\u003c-- lock(console_owner);\n vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394\n printk+0xba/0xed kernel/printk/printk.c:2084\n register_console+0x8b3/0xc10 kernel/printk/printk.c:2829\n univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681\n console_init+0x49d/0x6d3 kernel/printk/printk.c:2915\n start_kernel+0x5e9/0x879 init/main.c:713\n secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241\n\n-\u003e #0 (console_owner){....}-{0:0}:\n [...]\n lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734\n console_trylock_spinning kernel/printk/printk.c:1773 \n---truncated---",
"id": "GHSA-c7gr-crgh-pwcp",
"modified": "2025-03-17T18:31:47Z",
"published": "2025-03-17T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49441"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C864-85XV-823C
Vulnerability from github – Published: 2024-06-20 12:31 – Updated: 2024-10-29 21:30In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: avoid scanning potential huge holes
When using devm_request_free_mem_region() and devm_memremap_pages() to add ZONE_DEVICE memory, if requested free mem region's end pfn were huge(e.g., 0x400000000), the node_end_pfn() will be also huge (see move_pfn_range_to_zone()). Thus it creates a huge hole between node_start_pfn() and node_end_pfn().
We found on some AMD APUs, amdkfd requested such a free mem region and created a huge hole. In such a case, following code snippet was just doing busy test_bit() looping on the huge hole.
for (pfn = start_pfn; pfn < end_pfn; pfn++) { struct page *page = pfn_to_online_page(pfn); if (!page) continue; ... }
So we got a soft lockup:
watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221] CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Call Trace: ? kmemleak_scan+0x16a/0x440 kmemleak_write+0x306/0x3a0 ? common_file_perm+0x72/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
I did some tests with the patch.
(1) amdgpu module unloaded
before the patch:
real 0m0.976s user 0m0.000s sys 0m0.968s
after the patch:
real 0m0.981s user 0m0.000s sys 0m0.973s
(2) amdgpu module loaded
before the patch:
real 0m35.365s user 0m0.000s sys 0m35.354s
after the patch:
real 0m1.049s user 0m0.000s sys 0m1.042s
{
"affected": [],
"aliases": [
"CVE-2022-48731"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-20T12:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid scanning potential huge holes\n\nWhen using devm_request_free_mem_region() and devm_memremap_pages() to\nadd ZONE_DEVICE memory, if requested free mem region\u0027s end pfn were\nhuge(e.g., 0x400000000), the node_end_pfn() will be also huge (see\nmove_pfn_range_to_zone()). Thus it creates a huge hole between\nnode_start_pfn() and node_end_pfn().\n\nWe found on some AMD APUs, amdkfd requested such a free mem region and\ncreated a huge hole. In such a case, following code snippet was just\ndoing busy test_bit() looping on the huge hole.\n\n for (pfn = start_pfn; pfn \u003c end_pfn; pfn++) {\n\tstruct page *page = pfn_to_online_page(pfn);\n\t\tif (!page)\n\t\t\tcontinue;\n\t...\n }\n\nSo we got a soft lockup:\n\n watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221]\n CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1\n RIP: 0010:pfn_to_online_page+0x5/0xd0\n Call Trace:\n ? kmemleak_scan+0x16a/0x440\n kmemleak_write+0x306/0x3a0\n ? common_file_perm+0x72/0x170\n full_proxy_write+0x5c/0x90\n vfs_write+0xb9/0x260\n ksys_write+0x67/0xe0\n __x64_sys_write+0x1a/0x20\n do_syscall_64+0x3b/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nI did some tests with the patch.\n\n(1) amdgpu module unloaded\n\nbefore the patch:\n\n real 0m0.976s\n user 0m0.000s\n sys 0m0.968s\n\nafter the patch:\n\n real 0m0.981s\n user 0m0.000s\n sys 0m0.973s\n\n(2) amdgpu module loaded\n\nbefore the patch:\n\n real 0m35.365s\n user 0m0.000s\n sys 0m35.354s\n\nafter the patch:\n\n real 0m1.049s\n user 0m0.000s\n sys 0m1.042s",
"id": "GHSA-c864-85xv-823c",
"modified": "2024-10-29T21:30:48Z",
"published": "2024-06-20T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48731"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C8CC-57PQ-936R
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
md: fix resync softlockup when bitmap size is less than array size
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup:
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30
And the detailed process is as follows:
md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change
Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks.
Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be.
Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.
{
"affected": [],
"aliases": [
"CVE-2024-38598"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix resync softlockup when bitmap size is less than array size\n\nIs is reported that for dm-raid10, lvextend + lvchange --syncaction will\ntrigger following softlockup:\n\nkernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]\nCPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1\nRIP: 0010:_raw_spin_unlock_irq+0x13/0x30\nCall Trace:\n \u003cTASK\u003e\n md_bitmap_start_sync+0x6b/0xf0\n raid10_sync_request+0x25c/0x1b40 [raid10]\n md_do_sync+0x64b/0x1020\n md_thread+0xa7/0x170\n kthread+0xcf/0x100\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1a/0x30\n\nAnd the detailed process is as follows:\n\nmd_do_sync\n j = mddev-\u003eresync_min\n while (j \u003c max_sectors)\n sectors = raid10_sync_request(mddev, j, \u0026skipped)\n if (!md_bitmap_start_sync(..., \u0026sync_blocks))\n // md_bitmap_start_sync set sync_blocks to 0\n return sync_blocks + sectors_skippe;\n // sectors = 0;\n j += sectors;\n // j never change\n\nRoot cause is that commit 301867b1c168 (\"md/raid10: check\nslab-out-of-bounds in md_bitmap_get_counter\") return early from\nmd_bitmap_get_counter(), without setting returned blocks.\n\nFix this problem by always set returned blocks from\nmd_bitmap_get_counter\"(), as it used to be.\n\nNoted that this patch just fix the softlockup problem in kernel, the\ncase that bitmap size doesn\u0027t match array size still need to be fixed.",
"id": "GHSA-c8cc-57pq-936r",
"modified": "2026-05-12T12:31:56Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38598"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f5b73ef8fd6268cbc968b308d8eafe56fda97f3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43771597feba89a839c5f893716df88ae5c237ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5817f43ae1a118855676f57ef7ab50e37eac7482"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69296914bfd508c85935bf5f711cad9b0fe78492"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71e8e4f288e74a896b6d9cd194f3bab12bd7a10f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8bbc71315e0ae4bb7e37f8d43b915e1cb01a481b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9566b812c8f66160466cc1e29df6d3646add0b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4b9c764d48fa41caa24cfb4275f3aa9fb4bd798"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0e729af2eb6bee9eb58c4df1087f14ebaefe26b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C8XP-GQMX-G9XP
Vulnerability from github – Published: 2025-01-15 15:31 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
net: restrict SO_REUSEPORT to inet sockets
After blamed commit, crypto sockets could accidentally be destroyed from RCU call back, as spotted by zyzbot [1].
Trying to acquire a mutex in RCU callback is not allowed.
Restrict SO_REUSEPORT socket option to inet sockets.
v1 of this patch supported TCP, UDP and SCTP sockets, but fcnal-test.sh test needed RAW and ICMP support.
[1] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1 preempt_count: 100, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823 Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537 CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
{
"affected": [],
"aliases": [
"CVE-2024-57903"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-15T13:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: restrict SO_REUSEPORT to inet sockets\n\nAfter blamed commit, crypto sockets could accidentally be destroyed\nfrom RCU call back, as spotted by zyzbot [1].\n\nTrying to acquire a mutex in RCU callback is not allowed.\n\nRestrict SO_REUSEPORT socket option to inet sockets.\n\nv1 of this patch supported TCP, UDP and SCTP sockets,\nbut fcnal-test.sh test needed RAW and ICMP support.\n\n[1]\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:562\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1\npreempt_count: 100, expected: 0\nRCU nest depth: 0, expected: 0\n1 lock held by ksoftirqd/1/24:\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline]\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline]\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823\nPreemption disabled at:\n [\u003cffffffff8161c8c8\u003e] softirq_handle_begin kernel/softirq.c:402 [inline]\n [\u003cffffffff8161c8c8\u003e] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537\nCPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n __might_resched+0x5d4/0x780 kernel/sched/core.c:8758\n __mutex_lock_common kernel/locking/mutex.c:562 [inline]\n __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735\n crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179\n aead_release+0x3d/0x50 crypto/algif_aead.c:489\n alg_do_release crypto/af_alg.c:118 [inline]\n alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502\n __sk_destruct+0x58/0x5f0 net/core/sock.c:2260\n rcu_do_batch kernel/rcu/tree.c:2567 [inline]\n rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n run_ksoftirqd+0xca/0x130 kernel/softirq.c:950\n smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u003c/TASK\u003e",
"id": "GHSA-c8xp-gqmx-g9xp",
"modified": "2025-11-03T21:32:13Z",
"published": "2025-01-15T15:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57903"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3257813a3ae7462ac5cde04e120806f0c0776850"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/579cfa595af1e00ccc9c3a849a4add6bba8b4bad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b0af621c3f6ef9261cf6067812f2fd9943acb4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad2ad4cd11af9d63187cd074314b71b7cf8a2a59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad91a2dacbf8c26a446658cdd55e8324dfeff1e7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C9V7-FV5H-VR5J
Vulnerability from github – Published: 2024-11-19 21:31 – Updated: 2024-11-20 18:32In several functions of DescramblerImpl.cpp, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2018-9344"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T19:15:05Z",
"severity": "HIGH"
},
"details": "In several functions of DescramblerImpl.cpp, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-c9v7-fv5h-vr5j",
"modified": "2024-11-20T18:32:16Z",
"published": "2024-11-19T21:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9344"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CF96-W592-HC5W
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-09-19 15:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix lock ordering in btrfs_zone_activate()
The btrfs CI reported a lockdep warning as follows by running generic generic/129.
WARNING: possible circular locking dependency detected 6.7.0-rc5+ #1 Not tainted
kworker/u5:5/793427 is trying to acquire lock: ffff88813256d028 (&cache->lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x5e/0x130 but task is already holding lock: ffff88810a23a318 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x34/0x130 which lock already depends on the new lock.
the existing dependency chain (in reverse order) is: -> #1 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}: ... -> #0 (&cache->lock){+.+.}-{2:2}: ...
This is because we take fs_info->zone_active_bgs_lock after a block_group's lock in btrfs_zone_activate() while doing the opposite in other places.
Fix the issue by expanding the fs_info->zone_active_bgs_lock's critical section and taking it before a block_group's lock.
{
"affected": [],
"aliases": [
"CVE-2023-52668"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix lock ordering in btrfs_zone_activate()\n\nThe btrfs CI reported a lockdep warning as follows by running generic\ngeneric/129.\n\n WARNING: possible circular locking dependency detected\n 6.7.0-rc5+ #1 Not tainted\n ------------------------------------------------------\n kworker/u5:5/793427 is trying to acquire lock:\n ffff88813256d028 (\u0026cache-\u003elock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x5e/0x130\n but task is already holding lock:\n ffff88810a23a318 (\u0026fs_info-\u003ezone_active_bgs_lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x34/0x130\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n -\u003e #1 (\u0026fs_info-\u003ezone_active_bgs_lock){+.+.}-{2:2}:\n ...\n -\u003e #0 (\u0026cache-\u003elock){+.+.}-{2:2}:\n ...\n\nThis is because we take fs_info-\u003ezone_active_bgs_lock after a block_group\u0027s\nlock in btrfs_zone_activate() while doing the opposite in other places.\n\nFix the issue by expanding the fs_info-\u003ezone_active_bgs_lock\u0027s critical\nsection and taking it before a block_group\u0027s lock.",
"id": "GHSA-cf96-w592-hc5w",
"modified": "2025-09-19T15:31:07Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52668"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1908e9d01e5395adff68d9d308a0fb15337e6272"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f74989f5909cdec9b1274641f0fa306b15bb476"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b18f3b60b35a8c01c9a2a0f0d6424c6d73971dc3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CF9C-P3V8-R72C
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree during disable_unused
Doug reported [1] the following hung task:
INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20
The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread.
This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.
Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-27004"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n rpm_resume+0xe0/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n clk_pm_runtime_get+0x30/0xb0\n clk_disable_unused_subtree+0x58/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused+0x4c/0xe4\n do_one_initcall+0xcc/0x2d8\n do_initcall_level+0xa4/0x148\n do_initcalls+0x5c/0x9c\n do_basic_setup+0x24/0x30\n kernel_init_freeable+0xec/0x164\n kernel_init+0x28/0x120\n ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n schedule_preempt_disabled+0x2c/0x48\n __mutex_lock+0x238/0x488\n __mutex_lock_slowpath+0x1c/0x28\n mutex_lock+0x50/0x74\n clk_prepare_lock+0x7c/0x9c\n clk_core_prepare_lock+0x20/0x44\n clk_prepare+0x24/0x30\n clk_bulk_prepare+0x40/0xb0\n mdss_runtime_resume+0x54/0x1c8\n pm_generic_runtime_resume+0x30/0x44\n __genpd_runtime_resume+0x68/0x7c\n genpd_runtime_resume+0x108/0x1f4\n __rpm_callback+0x84/0x144\n rpm_callback+0x30/0x88\n rpm_resume+0x1f4/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n __device_attach+0xe0/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n device_add+0x644/0x814\n mipi_dsi_device_register_full+0xe4/0x170\n devm_mipi_dsi_device_register_full+0x28/0x70\n ti_sn_bridge_probe+0x1dc/0x2c0\n auxiliary_bus_probe+0x4c/0x94\n really_probe+0xcc/0x2c8\n __driver_probe_device+0xa8/0x130\n driver_probe_device+0x48/0x110\n __device_attach_driver+0xa4/0xcc\n bus_for_each_drv+0x8c/0xd8\n __device_attach+0xf8/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n deferred_probe_work_func+0x9c/0xd8\n process_one_work+0x148/0x518\n worker_thread+0x138/0x350\n kthread+0x138/0x1e0\n ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0027ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0027re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0027t have the chance to\nschedule away with the prepare_lock held. Let\u0027s fix this immediate\nproblem that can be\n---truncated---",
"id": "GHSA-cf9c-p3v8-r72c",
"modified": "2026-05-12T12:31:44Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27004"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/115554862294397590088ba02f11f2aba6d5016c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/253ab38d1ee652a596942156978a233970d185ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4af115f1a20a3d9093586079206ee37c2ac55123"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60ff482c4205a5aac3b0595ab794cfd62295dab5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a29ec0465dce0b871003698698ac6fa92c9a5034"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a424e713e0cc33d4b969cfda25b9f46df4d7b5bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e581cf5d216289ef292d1a4036d53ce90e122469"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CFPG-Q83X-6923
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: add missing return after LLCP_CLOSED checks
In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free.
Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through.
{
"affected": [],
"aliases": [
"CVE-2026-31629"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:42Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: llcp: add missing return after LLCP_CLOSED checks\n\nIn nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket\nstate is LLCP_CLOSED, the code correctly calls release_sock() and\nnfc_llcp_sock_put() but fails to return. Execution falls through to\nthe remainder of the function, which calls release_sock() and\nnfc_llcp_sock_put() again. This results in a double release_sock()\nand a refcount underflow via double nfc_llcp_sock_put(), leading to\na use-after-free.\n\nAdd the missing return statements after the LLCP_CLOSED branches\nin both functions to prevent the fall-through.",
"id": "GHSA-cfpg-q83x-6923",
"modified": "2026-06-01T18:31:28Z",
"published": "2026-04-24T15:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31629"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0eb1263a3b8c36418c9ba295c9ab3abed664edbf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b5dd4632966c39da6ba74dbc8689b309065e82c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/665315df9c3486cb213fc44d83cc8bcd47fe0d26"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/796e0cac058252d0ad34ebe288e6f7979b5fc9b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8977fad2b3c6eefd414131168d597c5d1d5e1abf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b49e2a4b8219a2fc5cebf94f4ec34e509aff8a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aba4712e8f0381cd5d196534ce2ad082626a5ab6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2a23529593d011fb433a3d711fc597ed6a6bd2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff3d9e8f7244293e303f7b6ef70774291c7c27e9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.