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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-R7XW-J6RQ-F93P
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921s: fix potential hung tasks during chip recovery
During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device.
This patch prevents the execution of stat_worker during the chip recovery.
{
"affected": [],
"aliases": [
"CVE-2024-40977"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7921s: fix potential hung tasks during chip recovery\n\nDuring chip recovery (e.g. chip reset), there is a possible situation that\nkernel worker reset_work is holding the lock and waiting for kernel thread\nstat_worker to be parked, while stat_worker is waiting for the release of\nthe same lock.\nIt causes a deadlock resulting in the dumping of hung tasks messages and\npossible rebooting of the device.\n\nThis patch prevents the execution of stat_worker during the chip recovery.",
"id": "GHSA-r7xw-j6rq-f93p",
"modified": "2025-11-04T00:30:56Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40977"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/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-R8HV-J9G9-64G6
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-11 18:31In the Linux kernel, the following vulnerability has been resolved:
cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated
A chain of commits going back to v7.0 reworked rmdir to satisfy the controller invariant that a subsystem's ->css_offline() must not run while tasks are still doing kernel-side work in the cgroup.
[1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out") [2] a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") [3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir") [4] 4c56a8ac6869 ("cgroup: Fix cgroup_drain_dying() testing the wrong condition") [5] 13e786b64bd3 ("cgroup: Increment nr_dying_subsys_* from rmdir context")
[1] moved task cset unlink from do_exit() to finish_task_switch() so a task's cset link drops only after the task has fully stopped scheduling. That made tasks past exit_signals() linger on cset->tasks until their final context switch, which led to a series of problems as what userspace expected to see after rmdir diverged from what the kernel needs to wait for. [2]-[5] tried to bridge that divergence: [2] filtered the exiting tasks from cgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4] fixed the wait's condition; [5] made nr_dying_subsys_* visible synchronously.
The cgroup_drain_dying() wait in [3] turned out to be a dead end. When the rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g. host PID 1 systemd reaping orphan pids that were re-parented to it during the same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those pids to free, the pids can't free because PID 1 is the reaper and it's stuck in rmdir, and the system A-A deadlocks. No internal lock ordering breaks this; the wait itself is the bug.
The css killing side that drove the original reorder, however, can be made cleanly asynchronous: ->css_offline() is already async, run from css_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to make that chain start only after all tasks have left the cgroup. rmdir's user-visible side then returns as soon as cgroup.procs and friends are empty, while ->css_offline() still runs only after the cgroup is fully drained.
Verified by the original reproducer (pidns teardown + zombie reaper, runs under vng) which hangs vanilla and succeeds here, and by per-commit deterministic repros for [2], [3], [4], [5] with a boot parameter that widens the post-exit_signals() window so each state is reliably reachable. Some stress tests on top of that.
cgroup_apply_control_disable() has the same shape of pre-existing race: when a controller is disabled via subtree_control, kill_css() ran synchronously while tasks past exit_signals() could still be linked to the cgroup's csets, and ->css_offline() could fire before they drained. This patch preserves the existing synchronous behavior at that call site (kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch will defer kill_css_finish() there using a per-css trigger.
This seems like the right approach and I don't see problems with it. The changes are somewhat invasive but not excessively so, so backporting to -stable should be okay. If something does turn out to be wrong, the fallback is to revert the entire chain ([1]-[5]) and rework in the development branch instead.
v2: Pin cgrp across the deferred destroy work with explicit cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1 wasn't actually broken (ordered cgroup_offline_wq + queue_work order in cgroup_task_dead() saved it) but the explicit ref removes the dependency on those non-obvious invariants. Also note the pre-existing cgroup_apply_control_disable() race in the description; a follow-up will defer kill_css_finish() there.
{
"affected": [],
"aliases": [
"CVE-2026-46223"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated\n\nA chain of commits going back to v7.0 reworked rmdir to satisfy the\ncontroller invariant that a subsystem\u0027s -\u003ecss_offline() must not run while\ntasks are still doing kernel-side work in the cgroup.\n\n[1] d245698d727a (\"cgroup: Defer task cgroup unlink until after the task is done switching out\")\n[2] a72f73c4dd9b (\"cgroup: Don\u0027t expose dead tasks in cgroup\")\n[3] 1b164b876c36 (\"cgroup: Wait for dying tasks to leave on rmdir\")\n[4] 4c56a8ac6869 (\"cgroup: Fix cgroup_drain_dying() testing the wrong condition\")\n[5] 13e786b64bd3 (\"cgroup: Increment nr_dying_subsys_* from rmdir context\")\n\n[1] moved task cset unlink from do_exit() to finish_task_switch() so a\ntask\u0027s cset link drops only after the task has fully stopped scheduling.\nThat made tasks past exit_signals() linger on cset-\u003etasks until their final\ncontext switch, which led to a series of problems as what userspace expected\nto see after rmdir diverged from what the kernel needs to wait for. [2]-[5]\ntried to bridge that divergence: [2] filtered the exiting tasks from\ncgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4]\nfixed the wait\u0027s condition; [5] made nr_dying_subsys_* visible\nsynchronously.\n\nThe cgroup_drain_dying() wait in [3] turned out to be a dead end. When the\nrmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g.\nhost PID 1 systemd reaping orphan pids that were re-parented to it during\nthe same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those\npids to free, the pids can\u0027t free because PID 1 is the reaper and it\u0027s stuck\nin rmdir, and the system A-A deadlocks. No internal lock ordering breaks\nthis; the wait itself is the bug.\n\nThe css killing side that drove the original reorder, however, can be made\ncleanly asynchronous: -\u003ecss_offline() is already async, run from\ncss_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to\nmake that chain start only after all tasks have left the cgroup. rmdir\u0027s\nuser-visible side then returns as soon as cgroup.procs and friends are\nempty, while -\u003ecss_offline() still runs only after the cgroup is fully\ndrained.\n\nVerified by the original reproducer (pidns teardown + zombie reaper, runs\nunder vng) which hangs vanilla and succeeds here, and by per-commit\ndeterministic repros for [2], [3], [4], [5] with a boot parameter that\nwidens the post-exit_signals() window so each state is reliably reachable.\nSome stress tests on top of that.\n\ncgroup_apply_control_disable() has the same shape of pre-existing race:\nwhen a controller is disabled via subtree_control, kill_css() ran\nsynchronously while tasks past exit_signals() could still be linked to\nthe cgroup\u0027s csets, and -\u003ecss_offline() could fire before they drained.\nThis patch preserves the existing synchronous behavior at that call site\n(kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch\nwill defer kill_css_finish() there using a per-css trigger.\n\nThis seems like the right approach and I don\u0027t see problems with it. The\nchanges are somewhat invasive but not excessively so, so backporting to\n-stable should be okay. If something does turn out to be wrong, the fallback\nis to revert the entire chain ([1]-[5]) and rework in the development branch\ninstead.\n\nv2: Pin cgrp across the deferred destroy work with explicit\n cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1\n wasn\u0027t actually broken (ordered cgroup_offline_wq + queue_work order\n in cgroup_task_dead() saved it) but the explicit ref removes the\n dependency on those non-obvious invariants. Also note the\n pre-existing cgroup_apply_control_disable() race in the description;\n a follow-up will defer kill_css_finish() there.",
"id": "GHSA-r8hv-j9g9-64g6",
"modified": "2026-06-11T18:31:31Z",
"published": "2026-05-28T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46223"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33fa2e6b1507a0a377a151a8826438bedad1d0b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93618edf753838a727dbff63c7c291dee22d656b"
}
],
"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-R95C-H52X-X56P
Vulnerability from github – Published: 2025-09-15 15:31 – Updated: 2025-12-04 15:30In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix deadlock triggered by cancel_delayed_work_syn()
The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-53233"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T15:15:50Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix deadlock triggered by cancel_delayed_work_syn()\n\nThe following LOCKDEP was detected:\n\t\tWorkqueue: events smc_lgr_free_work [smc]\n\t\tWARNING: possible circular locking dependency detected\n\t\t6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted\n\t\t------------------------------------------------------\n\t\tkworker/3:0/176251 is trying to acquire lock:\n\t\t00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},\n\t\t\tat: __flush_workqueue+0x7a/0x4f0\n\t\tbut task is already holding lock:\n\t\t0000037fffe97dc8 ((work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework)){+.+.}-{0:0},\n\t\t\tat: process_one_work+0x232/0x730\n\t\twhich lock already depends on the new lock.\n\t\tthe existing dependency chain (in reverse order) is:\n\t\t-\u003e #4 ((work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework)){+.+.}-{0:0}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t __flush_work+0x76/0xf0\n\t\t __cancel_work_timer+0x170/0x220\n\t\t __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]\n\t\t smc_connect_rdma+0x15e/0x418 [smc]\n\t\t __smc_connect+0x234/0x480 [smc]\n\t\t smc_connect+0x1d6/0x230 [smc]\n\t\t __sys_connect+0x90/0xc0\n\t\t __do_sys_socketcall+0x186/0x370\n\t\t __do_syscall+0x1da/0x208\n\t\t system_call+0x82/0xb0\n\t\t-\u003e #3 (smc_client_lgr_pending){+.+.}-{3:3}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t __mutex_lock+0x96/0x8e8\n\t\t mutex_lock_nested+0x32/0x40\n\t\t smc_connect_rdma+0xa4/0x418 [smc]\n\t\t __smc_connect+0x234/0x480 [smc]\n\t\t smc_connect+0x1d6/0x230 [smc]\n\t\t __sys_connect+0x90/0xc0\n\t\t __do_sys_socketcall+0x186/0x370\n\t\t __do_syscall+0x1da/0x208\n\t\t system_call+0x82/0xb0\n\t\t-\u003e #2 (sk_lock-AF_SMC){+.+.}-{0:0}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t lock_sock_nested+0x46/0xa8\n\t\t smc_tx_work+0x34/0x50 [smc]\n\t\t process_one_work+0x30c/0x730\n\t\t worker_thread+0x62/0x420\n\t\t kthread+0x138/0x150\n\t\t __ret_from_fork+0x3c/0x58\n\t\t ret_from_fork+0xa/0x40\n\t\t-\u003e #1 ((work_completion)(\u0026(\u0026smc-\u003econn.tx_work)-\u003ework)){+.+.}-{0:0}:\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t process_one_work+0x2bc/0x730\n\t\t worker_thread+0x62/0x420\n\t\t kthread+0x138/0x150\n\t\t __ret_from_fork+0x3c/0x58\n\t\t ret_from_fork+0xa/0x40\n\t\t-\u003e #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:\n\t\t check_prev_add+0xd8/0xe88\n\t\t validate_chain+0x70c/0xb20\n\t\t __lock_acquire+0x58e/0xbd8\n\t\t lock_acquire.part.0+0xe2/0x248\n\t\t lock_acquire+0xac/0x1c8\n\t\t __flush_workqueue+0xaa/0x4f0\n\t\t drain_workqueue+0xaa/0x158\n\t\t destroy_workqueue+0x44/0x2d8\n\t\t smc_lgr_free+0x9e/0xf8 [smc]\n\t\t process_one_work+0x30c/0x730\n\t\t worker_thread+0x62/0x420\n\t\t kthread+0x138/0x150\n\t\t __ret_from_fork+0x3c/0x58\n\t\t ret_from_fork+0xa/0x40\n\t\tother info that might help us debug this:\n\t\tChain exists of:\n\t\t (wq_completion)smc_tx_wq-00000000#2\n\t \t --\u003e smc_client_lgr_pending\n\t\t --\u003e (work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework)\n\t\t Possible unsafe locking scenario:\n\t\t CPU0 CPU1\n\t\t ---- ----\n\t\t lock((work_completion)(\u0026(\u0026lgr-\u003efree_work)-\u003ework));\n\t\t lock(smc_client_lgr_pending);\n\t\t lock((work_completion)\n\t\t\t\t\t(\u0026(\u0026lgr-\u003efree_work)-\u003ework));\n\t\t lock((wq_completion)smc_tx_wq-00000000#2);\n\t\t *** DEADLOCK ***\n\t\t2 locks held by kworker/3:0/176251:\n\t\t #0: 0000000080183548\n\t\t\t((wq_completion)events){+.+.}-{0:0},\n\t\t\t\tat: process_one_work+0x232/0x730\n\t\t #1: 0000037fffe97dc8\n\t\t\t((work_completion)\n\t\t\t (\u0026(\u0026lgr-\u003efree_work)-\u003ework)){+.+.}-{0:0},\n\t\t\t\tat: process_one_work+0x232/0x730\n\t\tstack backtr\n---truncated---",
"id": "GHSA-r95c-h52x-x56p",
"modified": "2025-12-04T15:30:32Z",
"published": "2025-09-15T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53233"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13085e1b5cab8ad802904d72e6a6dae85ae0cd20"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3517584cf1b35bd02f4a90267ddf9dcf17bd9c87"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9708efad9ba5095b9bb7916e11a135b3bd66c071"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b615238e5bc01e13dc0610febddc1ca99bab1df6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9ca2257150272df1b8d9ebe5059197ffea6e913"
}
],
"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-RCQF-HC64-M737
Vulnerability from github – Published: 2024-06-03 09:30 – Updated: 2025-09-18 04:12In the Linux kernel, the following vulnerability has been resolved:
thermal/debugfs: Fix two locking issues with thermal zone debug
With the current thermal zone locking arrangement in the debugfs code, user space can open the "mitigations" file for a thermal zone before the zone's debugfs pointer is set which will result in a NULL pointer dereference in tze_seq_start().
Moreover, thermal_debug_tz_remove() is not called under the thermal zone lock, so it can run in parallel with the other functions accessing the thermal zone's struct thermal_debugfs object. Then, it may clear tz->debugfs after one of those functions has checked it and the struct thermal_debugfs object may be freed prematurely.
To address the first problem, pass a pointer to the thermal zone's struct thermal_debugfs object to debugfs_create_file() in thermal_debug_tz_add() and make tze_seq_start(), tze_seq_next(), tze_seq_stop(), and tze_seq_show() retrieve it from s->private instead of a pointer to the thermal zone object. This will ensure that tz_debugfs will be valid across the "mitigations" file accesses until thermal_debugfs_remove_id() called by thermal_debug_tz_remove() removes that file.
To address the second problem, use tz->lock in thermal_debug_tz_remove() around the tz->debugfs value check (in case the same thermal zone is removed at the same time in two different threads) and its reset to NULL.
Cc :6.8+ stable@vger.kernel.org # 6.8+
{
"affected": [],
"aliases": [
"CVE-2024-36961"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-03T08:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/debugfs: Fix two locking issues with thermal zone debug\n\nWith the current thermal zone locking arrangement in the debugfs code,\nuser space can open the \"mitigations\" file for a thermal zone before\nthe zone\u0027s debugfs pointer is set which will result in a NULL pointer\ndereference in tze_seq_start().\n\nMoreover, thermal_debug_tz_remove() is not called under the thermal\nzone lock, so it can run in parallel with the other functions accessing\nthe thermal zone\u0027s struct thermal_debugfs object. Then, it may clear\ntz-\u003edebugfs after one of those functions has checked it and the\nstruct thermal_debugfs object may be freed prematurely.\n\nTo address the first problem, pass a pointer to the thermal zone\u0027s\nstruct thermal_debugfs object to debugfs_create_file() in\nthermal_debug_tz_add() and make tze_seq_start(), tze_seq_next(),\ntze_seq_stop(), and tze_seq_show() retrieve it from s-\u003eprivate\ninstead of a pointer to the thermal zone object. This will ensure\nthat tz_debugfs will be valid across the \"mitigations\" file accesses\nuntil thermal_debugfs_remove_id() called by thermal_debug_tz_remove()\nremoves that file.\n\nTo address the second problem, use tz-\u003elock in thermal_debug_tz_remove()\naround the tz-\u003edebugfs value check (in case the same thermal zone is\nremoved at the same time in two different threads) and its reset to NULL.\n\nCc :6.8+ \u003cstable@vger.kernel.org\u003e # 6.8+",
"id": "GHSA-rcqf-hc64-m737",
"modified": "2025-09-18T04:12:19Z",
"published": "2024-06-03T09:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36961"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c57bdd0505422d5ccd2df541d993aec978c842e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7f7c37271787a7f77d7eedc132b0b419a76b4c8"
}
],
"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-RGGX-C6X2-98G3
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 18:30In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix exception exit lock checking for subprogs
process_bpf_exit_full() passes check_lock = !curframe to check_resource_leak(), which is false in cases when bpf_throw() is called from a static subprog. This makes check_resource_leak() to skip validation of active_rcu_locks, active_preempt_locks, and active_irq_id on exception exits from subprogs.
At runtime bpf_throw() unwinds the stack via ORC without releasing any user-acquired locks, which may cause various issues as the result.
Fix by setting check_lock = true for exception exits regardless of curframe, since exceptions bypass all intermediate frame cleanup. Update the error message prefix to "bpf_throw" for exception exits to distinguish them from normal BPF_EXIT.
Fix reject_subprog_with_rcu_read_lock test which was previously passing for the wrong reason. Test program returned directly from the subprog call without closing the RCU section, so the error was triggered by the unclosed RCU lock on normal exit, not by bpf_throw. Update __msg annotations for affected tests to match the new "bpf_throw" error prefix.
The spin_lock case is not affected because they are already checked [1] at the call site in do_check_insn() before bpf_throw can run.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v7.0-rc4#n21098
{
"affected": [],
"aliases": [
"CVE-2026-31526"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix exception exit lock checking for subprogs\n\nprocess_bpf_exit_full() passes check_lock = !curframe to\ncheck_resource_leak(), which is false in cases when bpf_throw() is\ncalled from a static subprog. This makes check_resource_leak() to skip\nvalidation of active_rcu_locks, active_preempt_locks, and\nactive_irq_id on exception exits from subprogs.\n\nAt runtime bpf_throw() unwinds the stack via ORC without releasing any\nuser-acquired locks, which may cause various issues as the result.\n\nFix by setting check_lock = true for exception exits regardless of\ncurframe, since exceptions bypass all intermediate frame\ncleanup. Update the error message prefix to \"bpf_throw\" for exception\nexits to distinguish them from normal BPF_EXIT.\n\nFix reject_subprog_with_rcu_read_lock test which was previously\npassing for the wrong reason. Test program returned directly from the\nsubprog call without closing the RCU section, so the error was\ntriggered by the unclosed RCU lock on normal exit, not by\nbpf_throw. Update __msg annotations for affected tests to match the\nnew \"bpf_throw\" error prefix.\n\nThe spin_lock case is not affected because they are already checked [1]\nat the call site in do_check_insn() before bpf_throw can run.\n\n[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c?h=v7.0-rc4#n21098",
"id": "GHSA-rggx-c6x2-98g3",
"modified": "2026-04-28T18:30:30Z",
"published": "2026-04-22T15:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31526"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a399f3117642494e35545f6ca397d3e177c1f9b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c2128505f61b504c79a20b89596feba61388112"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0281da1f2aa5c2fca3a05f79b86bea96591c358"
}
],
"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-RGX6-C7RP-8R4X
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-06-19 15:33In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/core) Protect regulator operations with mutex
The regulator operations pmbus_regulator_get_voltage(), pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage() access PMBus registers and shared data but were not protected by the update_lock mutex. This could lead to race conditions.
However, adding mutex protection directly to these functions causes a deadlock because pmbus_regulator_notify() (which calls regulator_notifier_call_chain()) is often called with the mutex already held (e.g., from pmbus_fault_handler()). If a regulator callback then calls one of the now-protected voltage functions, it will attempt to acquire the same mutex.
Rework pmbus_regulator_notify() to utilize a worker function to send notifications outside of the mutex protection. Events are stored as atomics in a per-page bitmask and processed by the worker.
Initialize the worker and its associated data during regulator registration, and ensure it is cancelled on device removal using devm_add_action_or_reset().
While at it, remove the unnecessary include of linux/of.h.
{
"affected": [],
"aliases": [
"CVE-2026-31486"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:46Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (pmbus/core) Protect regulator operations with mutex\n\nThe regulator operations pmbus_regulator_get_voltage(),\npmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()\naccess PMBus registers and shared data but were not protected by\nthe update_lock mutex. This could lead to race conditions.\n\nHowever, adding mutex protection directly to these functions causes\na deadlock because pmbus_regulator_notify() (which calls\nregulator_notifier_call_chain()) is often called with the mutex\nalready held (e.g., from pmbus_fault_handler()). If a regulator\ncallback then calls one of the now-protected voltage functions,\nit will attempt to acquire the same mutex.\n\nRework pmbus_regulator_notify() to utilize a worker function to\nsend notifications outside of the mutex protection. Events are\nstored as atomics in a per-page bitmask and processed by the worker.\n\nInitialize the worker and its associated data during regulator\nregistration, and ensure it is cancelled on device removal using\ndevm_add_action_or_reset().\n\nWhile at it, remove the unnecessary include of linux/of.h.",
"id": "GHSA-rgx6-c7rp-8r4x",
"modified": "2026-06-19T15:33:08Z",
"published": "2026-04-22T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31486"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c77ae315f3ce9d2c8e1609be74c9358c1fe4e07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e9d723d9f198b86f6882a84c501ba1f39e8d055"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/754bd2b4a084b90b5e7b630e1f423061a9b9b761"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/acf04e2863132f6d9222f71f3a76fb9782cbe061"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b26849cffaa7c43355b82e9bef3725e786973a1a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-RH96-4PX7-3VM8
Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning.
Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq().
{
"affected": [],
"aliases": [
"CVE-2024-38780"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T12:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf/sw-sync: don\u0027t enable IRQ from sync_print_obj()\n\nSince commit a6aa8fca4d79 (\"dma-buf/sw-sync: Reduce irqsave/irqrestore from\nknown context\") by error replaced spin_unlock_irqrestore() with\nspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite\nsync_print_obj() is called from sync_debugfs_show(), lockdep complains\ninconsistent lock state warning.\n\nUse plain spin_{lock,unlock}() for sync_print_obj(), for\nsync_debugfs_show() is already using spin_{lock,unlock}_irq().",
"id": "GHSA-rh96-4px7-3vm8",
"modified": "2026-05-12T12:31:57Z",
"published": "2024-06-21T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38780"
},
{
"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/165b25e3ee9333f7b04f8db43895beacb51582ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39"
},
{
"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-RJ28-PP8G-VC2R
Vulnerability from github – Published: 2024-06-24 15:31 – Updated: 2024-06-26 15:31In the Linux kernel, the following vulnerability has been resolved:
drm: zynqmp_dpsub: Always register bridge
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning:
[ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]---
(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)
{
"affected": [],
"aliases": [
"CVE-2024-38664"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-24T14:15:12Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: zynqmp_dpsub: Always register bridge\n\nWe must always register the DRM bridge, since zynqmp_dp_hpd_work_func\ncalls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be\ninitialized. We do this before zynqmp_dpsub_drm_init since that calls\ndrm_bridge_attach. This fixes the following lockdep warning:\n\n[ 19.217084] ------------[ cut here ]------------\n[ 19.227530] DEBUG_LOCKS_WARN_ON(lock-\u003emagic != lock)\n[ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550\n[ 19.241696] Modules linked in:\n[ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96\n[ 19.252046] Hardware name: xlnx,zynqmp (DT)\n[ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func\n[ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 19.269104] pc : __mutex_lock+0x4bc/0x550\n[ 19.273364] lr : __mutex_lock+0x4bc/0x550\n[ 19.277592] sp : ffffffc085c5bbe0\n[ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8\n[ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000\n[ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000\n[ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000\n[ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720\n[ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001\n[ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888\n[ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000\n[ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000\n[ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880\n[ 19.356581] Call trace:\n[ 19.359160] __mutex_lock+0x4bc/0x550\n[ 19.363032] mutex_lock_nested+0x24/0x30\n[ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c\n[ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54\n[ 19.376364] process_one_work+0x3ac/0x988\n[ 19.380660] worker_thread+0x398/0x694\n[ 19.384736] kthread+0x1bc/0x1c0\n[ 19.388241] ret_from_fork+0x10/0x20\n[ 19.392031] irq event stamp: 183\n[ 19.395450] hardirqs last enabled at (183): [\u003cffffffc0800b9278\u003e] finish_task_switch.isra.0+0xa8/0x2d4\n[ 19.405140] hardirqs last disabled at (182): [\u003cffffffc081ad3754\u003e] __schedule+0x714/0xd04\n[ 19.413612] softirqs last enabled at (114): [\u003cffffffc080133de8\u003e] srcu_invoke_callbacks+0x158/0x23c\n[ 19.423128] softirqs last disabled at (110): [\u003cffffffc080133de8\u003e] srcu_invoke_callbacks+0x158/0x23c\n[ 19.432614] ---[ end trace 0000000000000000 ]---\n\n(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)",
"id": "GHSA-rj28-pp8g-vc2r",
"modified": "2024-06-26T15:31:01Z",
"published": "2024-06-24T15:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38664"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/603661357056b5e5ba6d86f505fbc936eff396ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ead3eccf67bc8318b1ce95ed879b2cc05b4fce9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be3f3042391d061cfca2bd22630e0d101acea5fc"
}
],
"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-RJPX-6FRC-3VGP
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-17 15:30In the Linux kernel, the following vulnerability has been resolved:
PCI: pciehp: Avoid unnecessary device replacement check
Hot-removal of nested PCI hotplug ports suffers from a long-standing race condition which can lead to a deadlock: A parent hotplug port acquires pci_lock_rescan_remove(), then waits for pciehp to unbind from a child hotplug port. Meanwhile that child hotplug port tries to acquire pci_lock_rescan_remove() as well in order to remove its own children.
The deadlock only occurs if the parent acquires pci_lock_rescan_remove() first, not if the child happens to acquire it first.
Several workarounds to avoid the issue have been proposed and discarded over the years, e.g.:
https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/
A proper fix is being worked on, but needs more time as it is nontrivial and necessarily intrusive.
Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during system sleep") provokes more frequent occurrence of the deadlock when removing more than one Thunderbolt device during system sleep. The commit sought to detect device replacement, but also triggered on device removal. Differentiating reliably between replacement and removal is impossible because pci_get_dsn() returns 0 both if the device was removed, as well as if it was replaced with one lacking a Device Serial Number.
Avoid the more frequent occurrence of the deadlock by checking whether the hotplug port itself was hot-removed. If so, there's no sense in checking whether its child device was replaced.
This works because the ->resume_noirq() callback is invoked in top-down order for the entire hierarchy: A parent hotplug port detecting device replacement (or removal) marks all children as removed using pci_dev_set_disconnected() and a child hotplug port can then reliably detect being removed.
{
"affected": [],
"aliases": [
"CVE-2025-37843"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: pciehp: Avoid unnecessary device replacement check\n\nHot-removal of nested PCI hotplug ports suffers from a long-standing race\ncondition which can lead to a deadlock: A parent hotplug port acquires\npci_lock_rescan_remove(), then waits for pciehp to unbind from a child\nhotplug port. Meanwhile that child hotplug port tries to acquire\npci_lock_rescan_remove() as well in order to remove its own children.\n\nThe deadlock only occurs if the parent acquires pci_lock_rescan_remove()\nfirst, not if the child happens to acquire it first.\n\nSeveral workarounds to avoid the issue have been proposed and discarded\nover the years, e.g.:\n\nhttps://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/\n\nA proper fix is being worked on, but needs more time as it is nontrivial\nand necessarily intrusive.\n\nRecent commit 9d573d19547b (\"PCI: pciehp: Detect device replacement during\nsystem sleep\") provokes more frequent occurrence of the deadlock when\nremoving more than one Thunderbolt device during system sleep. The commit\nsought to detect device replacement, but also triggered on device removal.\nDifferentiating reliably between replacement and removal is impossible\nbecause pci_get_dsn() returns 0 both if the device was removed, as well as\nif it was replaced with one lacking a Device Serial Number.\n\nAvoid the more frequent occurrence of the deadlock by checking whether the\nhotplug port itself was hot-removed. If so, there\u0027s no sense in checking\nwhether its child device was replaced.\n\nThis works because the -\u003eresume_noirq() callback is invoked in top-down\norder for the entire hierarchy: A parent hotplug port detecting device\nreplacement (or removal) marks all children as removed using\npci_dev_set_disconnected() and a child hotplug port can then reliably\ndetect being removed.",
"id": "GHSA-rjpx-6frc-3vgp",
"modified": "2025-11-17T15:30:30Z",
"published": "2025-05-09T09:33:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37843"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d0bbd01f7c0ac7d1be9f85aaf2cd0baec34655f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7535d10a2c61baeff493300070cf04d9ddda216b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3260237aaadc9799107ccb940c6688195c4518d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e4a1d7defbc2d806540720a5adebe24ec3488683"
}
],
"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-RP89-9JXH-73FW
Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2024-10-01 18:31In the Linux kernel, the following vulnerability has been resolved:
drm/xe/client: fix deadlock in show_meminfo()
There is a real deadlock as well as sleeping in atomic() bug in here, if the bo put happens to be the last ref, since bo destruction wants to grab the same spinlock and sleeping locks. Fix that by dropping the ref using xe_bo_put_deferred(), and moving the final commit outside of the lock. Dropping the lock around the put is tricky since the bo can go out of scope and delete itself from the list, making it difficult to navigate to the next list entry.
(cherry picked from commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a)
{
"affected": [],
"aliases": [
"CVE-2024-46867"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-27T13:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/client: fix deadlock in show_meminfo()\n\nThere is a real deadlock as well as sleeping in atomic() bug in here, if\nthe bo put happens to be the last ref, since bo destruction wants to\ngrab the same spinlock and sleeping locks. Fix that by dropping the ref\nusing xe_bo_put_deferred(), and moving the final commit outside of the\nlock. Dropping the lock around the put is tricky since the bo can go\nout of scope and delete itself from the list, making it difficult to\nnavigate to the next list entry.\n\n(cherry picked from commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a)",
"id": "GHSA-rp89-9jxh-73fw",
"modified": "2024-10-01T18:31:17Z",
"published": "2024-09-27T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46867"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bd7ff293fc84792514aeafa06c5a17f05cb5f4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d3de463e23bfb1ff1567a32b099b1b3e5286a48"
}
],
"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"
}
]
}
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.