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-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"
}
]
}
GHSA-CGFP-5VMP-V4J6
Vulnerability from github – Published: 2025-03-18 21:31 – Updated: 2025-10-01 21:30In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix deadlock in concurrent rename whiteout and inode writeback
Following hung tasks: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0
[ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770
, are caused by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ↑ wb_wait_for_completion (Wait wb work) <-- deadlock!
Reproducer (Detail program in [Link]): 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consume out of space before kernel(mdelay) doing budget for whiteout
Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto tag 'out_release' in whiteout budget error handling path(It should at least recover dir i_size and unlock 4 ubifs inodes).
{
"affected": [],
"aliases": [
"CVE-2021-47637"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T06:37:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Fix deadlock in concurrent rename whiteout and inode writeback\n\nFollowing hung tasks:\n[ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132\n[ 77.028820] Call Trace:\n[ 77.029027] schedule+0x8c/0x1b0\n[ 77.029067] mutex_lock+0x50/0x60\n[ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs]\n[ 77.029117] __writeback_single_inode+0x43c/0x570\n[ 77.029128] writeback_sb_inodes+0x259/0x740\n[ 77.029148] wb_writeback+0x107/0x4d0\n[ 77.029163] wb_workfn+0x162/0x7b0\n\n[ 92.390442] task:aa state:D stack: 0 pid: 1506\n[ 92.390448] Call Trace:\n[ 92.390458] schedule+0x8c/0x1b0\n[ 92.390461] wb_wait_for_completion+0x82/0xd0\n[ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110\n[ 92.390472] writeback_inodes_sb_nr+0x14/0x20\n[ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs]\n[ 92.390503] do_rename.cold+0x7f/0x187 [ubifs]\n[ 92.390549] ubifs_rename+0x8b/0x180 [ubifs]\n[ 92.390571] vfs_rename+0xdb2/0x1170\n[ 92.390580] do_renameat2+0x554/0x770\n\n, are caused by concurrent rename whiteout and inode writeback processes:\n\trename_whiteout(Thread 1)\t wb_workfn(Thread2)\nubifs_rename\n do_rename\n lock_4_inodes (Hold ui_mutex)\n ubifs_budget_space\n make_free_space\n shrink_liability\n\t __writeback_inodes_sb_nr\n\t bdi_split_work_to_wbs (Queue new wb work)\n\t\t\t\t\t wb_do_writeback(wb work)\n\t\t\t\t\t\t__writeback_single_inode\n\t\t\t\t\t ubifs_write_inode\n\t\t\t\t\t LOCK(ui_mutex)\n\t\t\t\t\t\t\t \u2191\n\t wb_wait_for_completion (Wait wb work) \u003c-- deadlock!\n\nReproducer (Detail program in [Link]):\n 1. SYS_renameat2(\"/mp/dir/file\", \"/mp/dir/whiteout\", RENAME_WHITEOUT)\n 2. Consume out of space before kernel(mdelay) doing budget for whiteout\n\nFix it by doing whiteout space budget before locking ubifs inodes.\nBTW, it also fixes wrong goto tag \u0027out_release\u0027 in whiteout budget\nerror handling path(It should at least recover dir i_size and unlock\n4 ubifs inodes).",
"id": "GHSA-cgfp-5vmp-v4j6",
"modified": "2025-10-01T21:30:52Z",
"published": "2025-03-18T21:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47637"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b"
}
],
"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-CGVJ-GWGX-P5F7
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2024-08-21 18:31In the Linux kernel, the following vulnerability has been resolved:
mm: vmscan: remove deadlock due to throttling failing to make progress
A soft lockup bug in kcompactd was reported in a private bugzilla with the following visible in dmesg;
watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]
The machine had 256G of RAM with no swap and an earlier failed allocation indicated that node 0 where kcompactd was run was potentially unreclaimable;
Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes
Vlastimil Babka investigated a crash dump and found that a task migrating pages was trying to drain PCP lists;
PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: "kworker/u128:3" Call Trace: __schedule schedule schedule_timeout wait_for_completion __flush_work __drain_all_pages __alloc_pages_slowpath.constprop.114 __alloc_pages alloc_migration_target migrate_pages migrate_to_node do_migrate_pages cpuset_migrate_mm_workfn process_one_work worker_thread kthread ret_from_fork
This failure is specific to CONFIG_PREEMPT=n builds. The root of the problem is that kcompact0 is not rescheduling on a CPU while a task that has isolated a large number of the pages from the LRU is waiting on kcompact0 to reschedule so the pages can be released. While shrink_inactive_list() only loops once around too_many_isolated, reclaim can continue without rescheduling if sc->skipped_deactivate == 1 which could happen if there was no file LRU and the inactive anon list was not low.
{
"affected": [],
"aliases": [
"CVE-2022-48800"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmscan: remove deadlock due to throttling failing to make progress\n\nA soft lockup bug in kcompactd was reported in a private bugzilla with\nthe following visible in dmesg;\n\n watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479]\n watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479]\n watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479]\n watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]\n\nThe machine had 256G of RAM with no swap and an earlier failed\nallocation indicated that node 0 where kcompactd was run was potentially\nunreclaimable;\n\n Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB\n inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB\n mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp:\n 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB\n kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes\n\nVlastimil Babka investigated a crash dump and found that a task\nmigrating pages was trying to drain PCP lists;\n\n PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: \"kworker/u128:3\"\n Call Trace:\n __schedule\n schedule\n schedule_timeout\n wait_for_completion\n __flush_work\n __drain_all_pages\n __alloc_pages_slowpath.constprop.114\n __alloc_pages\n alloc_migration_target\n migrate_pages\n migrate_to_node\n do_migrate_pages\n cpuset_migrate_mm_workfn\n process_one_work\n worker_thread\n kthread\n ret_from_fork\n\nThis failure is specific to CONFIG_PREEMPT=n builds. The root of the\nproblem is that kcompact0 is not rescheduling on a CPU while a task that\nhas isolated a large number of the pages from the LRU is waiting on\nkcompact0 to reschedule so the pages can be released. While\nshrink_inactive_list() only loops once around too_many_isolated, reclaim\ncan continue without rescheduling if sc-\u003eskipped_deactivate == 1 which\ncould happen if there was no file LRU and the inactive anon list was not\nlow.",
"id": "GHSA-cgvj-gwgx-p5f7",
"modified": "2024-08-21T18:31:27Z",
"published": "2024-07-16T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48800"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3980cff6349687f73d5109f156f23cb261c24164"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b485c6f1f9f54b81443efda5f3d8a5036ba2cd91"
}
],
"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-CH7H-W2MM-GM7M
Vulnerability from github – Published: 2022-08-27 00:00 – Updated: 2025-02-28 15:30A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.
{
"affected": [],
"aliases": [
"CVE-2021-3735"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-26T16:15:00Z",
"severity": "MODERATE"
},
"details": "A deadlock issue was found in the AHCI controller device of QEMU. It occurs on a software reset (ahci_reset_port) while handling a host-to-device Register FIS (Frame Information Structure) packet from the guest. A privileged user inside the guest could use this flaw to hang the QEMU process on the host, resulting in a denial of service condition. The highest threat from this vulnerability is to system availability.",
"id": "GHSA-ch7h-w2mm-gm7m",
"modified": "2025-02-28T15:30:57Z",
"published": "2022-08-27T00:00:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3735"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2021-3735"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1997184"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2021-3735"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250228-0009"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CJ4H-CH85-55P9
Vulnerability from github – Published: 2025-10-04 18:31 – Updated: 2026-02-10 15:30In the Linux kernel, the following vulnerability has been resolved:
USB: Gadget: core: Help prevent panic during UVC unconfigure
Avichal Rakesh reported a kernel panic that occurred when the UVC gadget driver was removed from a gadget's configuration. The panic involves a somewhat complicated interaction between the kernel driver and a userspace component (as described in the Link tag below), but the analysis did make one thing clear: The Gadget core should accomodate gadget drivers calling usb_gadget_deactivate() as part of their unbind procedure.
Currently this doesn't work. gadget_unbind_driver() calls driver->unbind() while holding the udc->connect_lock mutex, and usb_gadget_deactivate() attempts to acquire that mutex, which will result in a deadlock.
The simple fix is for gadget_unbind_driver() to release the mutex when invoking the ->unbind() callback. There is no particular reason for it to be holding the mutex at that time, and the mutex isn't held while the ->bind() callback is invoked. So we'll drop the mutex before performing the unbind callback and reacquire it afterward.
We'll also add a couple of comments to usb_gadget_activate() and usb_gadget_deactivate(). Because they run in process context they must not be called from a gadget driver's ->disconnect() callback, which (according to the kerneldoc for struct usb_gadget_driver in include/linux/usb/gadget.h) may run in interrupt context. This may help prevent similar bugs from arising in the future.
{
"affected": [],
"aliases": [
"CVE-2023-53580"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T16:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: Gadget: core: Help prevent panic during UVC unconfigure\n\nAvichal Rakesh reported a kernel panic that occurred when the UVC\ngadget driver was removed from a gadget\u0027s configuration. The panic\ninvolves a somewhat complicated interaction between the kernel driver\nand a userspace component (as described in the Link tag below), but\nthe analysis did make one thing clear: The Gadget core should\naccomodate gadget drivers calling usb_gadget_deactivate() as part of\ntheir unbind procedure.\n\nCurrently this doesn\u0027t work. gadget_unbind_driver() calls\ndriver-\u003eunbind() while holding the udc-\u003econnect_lock mutex, and\nusb_gadget_deactivate() attempts to acquire that mutex, which will\nresult in a deadlock.\n\nThe simple fix is for gadget_unbind_driver() to release the mutex when\ninvoking the -\u003eunbind() callback. There is no particular reason for\nit to be holding the mutex at that time, and the mutex isn\u0027t held\nwhile the -\u003ebind() callback is invoked. So we\u0027ll drop the mutex\nbefore performing the unbind callback and reacquire it afterward.\n\nWe\u0027ll also add a couple of comments to usb_gadget_activate() and\nusb_gadget_deactivate(). Because they run in process context they\nmust not be called from a gadget driver\u0027s -\u003edisconnect() callback,\nwhich (according to the kerneldoc for struct usb_gadget_driver in\ninclude/linux/usb/gadget.h) may run in interrupt context. This may\nhelp prevent similar bugs from arising in the future.",
"id": "GHSA-cj4h-ch85-55p9",
"modified": "2026-02-10T15:30:20Z",
"published": "2025-10-04T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53580"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65dadb2beeb7360232b09ebc4585b54475dfee06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c1edc00db65f6d4408b3d1cd845e8da3b9e0ca4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bed19d95fcb9c98dfaa9585922b39a2dfba7898d"
}
],
"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-CJWF-5VH9-W48G
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2024-10-25 15:31In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count
If qi_submit_sync() is invoked with 0 invalidation descriptors (for instance, for DMA draining purposes), we can run into a bug where a submitting thread fails to detect the completion of invalidation_wait. Subsequently, this led to a soft lockup. Currently, there is no impact by this bug on the existing users because no callers are submitting invalidations with 0 descriptors. This fix will enable future users (such as DMA drain) calling qi_submit_sync() with 0 count.
Suppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while concurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both threads then enter a while loop, waiting for their respective descriptors to complete. T1 detects its completion (i.e., T1's invalidation_wait status changes to QI_DONE by HW) and proceeds to call reclaim_free_desc() to reclaim all descriptors, potentially including adjacent ones of other threads that are also marked as QI_DONE.
During this time, while T2 is waiting to acquire the qi->q_lock, the IOMMU hardware may complete the invalidation for T2, setting its status to QI_DONE. However, if T1's execution of reclaim_free_desc() frees T2's invalidation_wait descriptor and changes its status to QI_FREE, T2 will not observe the QI_DONE status for its invalidation_wait and will indefinitely remain stuck.
This soft lockup does not occur when only non-zero descriptors are submitted.In such cases, invalidation descriptors are interspersed among wait descriptors with the status QI_IN_USE, acting as barriers. These barriers prevent the reclaim code from mistakenly freeing descriptors belonging to other submitters.
Considered the following example timeline: T1 T2 ======================================== ID1 WD1 while(WD1!=QI_DONE) unlock lock WD1=QI_DONE WD2 while(WD2!=QI_DONE) unlock lock WD1==QI_DONE? ID1=QI_DONE WD2=DONE reclaim() ID1=FREE WD1=FREE WD2=FREE unlock soft lockup! T2 never sees QI_DONE in WD2
Where: ID = invalidation descriptor WD = wait descriptor * Written by hardware
The root of the problem is that the descriptor status QI_DONE flag is used for two conflicting purposes: 1. signal a descriptor is ready for reclaim (to be freed) 2. signal by the hardware that a wait descriptor is complete
The solution (in this patch) is state separation by using QI_FREE flag for #1.
Once a thread's invalidation descriptors are complete, their status would be set to QI_FREE. The reclaim_free_desc() function would then only free descriptors marked as QI_FREE instead of those marked as QI_DONE. This change ensures that T2 (from the previous example) will correctly observe the completion of its invalidation_wait (marked as QI_DONE).
{
"affected": [],
"aliases": [
"CVE-2024-49993"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count\n\nIf qi_submit_sync() is invoked with 0 invalidation descriptors (for\ninstance, for DMA draining purposes), we can run into a bug where a\nsubmitting thread fails to detect the completion of invalidation_wait.\nSubsequently, this led to a soft lockup. Currently, there is no impact\nby this bug on the existing users because no callers are submitting\ninvalidations with 0 descriptors. This fix will enable future users\n(such as DMA drain) calling qi_submit_sync() with 0 count.\n\nSuppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while\nconcurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both\nthreads then enter a while loop, waiting for their respective descriptors\nto complete. T1 detects its completion (i.e., T1\u0027s invalidation_wait status\nchanges to QI_DONE by HW) and proceeds to call reclaim_free_desc() to\nreclaim all descriptors, potentially including adjacent ones of other\nthreads that are also marked as QI_DONE.\n\nDuring this time, while T2 is waiting to acquire the qi-\u003eq_lock, the IOMMU\nhardware may complete the invalidation for T2, setting its status to\nQI_DONE. However, if T1\u0027s execution of reclaim_free_desc() frees T2\u0027s\ninvalidation_wait descriptor and changes its status to QI_FREE, T2 will\nnot observe the QI_DONE status for its invalidation_wait and will\nindefinitely remain stuck.\n\nThis soft lockup does not occur when only non-zero descriptors are\nsubmitted.In such cases, invalidation descriptors are interspersed among\nwait descriptors with the status QI_IN_USE, acting as barriers. These\nbarriers prevent the reclaim code from mistakenly freeing descriptors\nbelonging to other submitters.\n\nConsidered the following example timeline:\n\tT1\t\t\tT2\n========================================\n\tID1\n\tWD1\n\twhile(WD1!=QI_DONE)\n\tunlock\n\t\t\t\tlock\n\tWD1=QI_DONE*\t\tWD2\n\t\t\t\twhile(WD2!=QI_DONE)\n\t\t\t\tunlock\n\tlock\n\tWD1==QI_DONE?\n\tID1=QI_DONE\t\tWD2=DONE*\n\treclaim()\n\tID1=FREE\n\tWD1=FREE\n\tWD2=FREE\n\tunlock\n\t\t\t\tsoft lockup! T2 never sees QI_DONE in WD2\n\nWhere:\nID = invalidation descriptor\nWD = wait descriptor\n* Written by hardware\n\nThe root of the problem is that the descriptor status QI_DONE flag is used\nfor two conflicting purposes:\n1. signal a descriptor is ready for reclaim (to be freed)\n2. signal by the hardware that a wait descriptor is complete\n\nThe solution (in this patch) is state separation by using QI_FREE flag\nfor #1.\n\nOnce a thread\u0027s invalidation descriptors are complete, their status would\nbe set to QI_FREE. The reclaim_free_desc() function would then only\nfree descriptors marked as QI_FREE instead of those marked as\nQI_DONE. This change ensures that T2 (from the previous example) will\ncorrectly observe the completion of its invalidation_wait (marked as\nQI_DONE).",
"id": "GHSA-cjwf-5vh9-w48g",
"modified": "2024-10-25T15:31:26Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49993"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/07e4e92f84b7d3018b7064ef8d8438aeb54a2ca5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cf74230c139f208b7fb313ae0054386eee31a81"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8840dc73ac9e1028291458ef1429ec3c2524ffec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92ba5b014d5435dd7a1ee02a2c7f2a0e8fe06c36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de9e7f68762585f7532de8a06de9485bf39dbd38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dfdbc5ba10fb792c9d6d12ba8cb6e465f97365ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e03f00aa4a6c0c49c17857a4048f586636abdc32"
}
],
"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.