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.
713 vulnerabilities reference this CWE, most recent first.
GHSA-QCJH-44GV-7799
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-23 21:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock between reflink and transaction commit when using flushoncommit
When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node.
The deadlock happens like this:
1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page();
2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc;
3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero);
4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED).
So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A.
Syzbot recently reported this with the following stack traces:
INFO: task kworker/u8:7:1053 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid: ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-53122"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock between reflink and transaction commit when using flushoncommit\n\nWhen using the flushoncommit mount option, we can have a deadlock between\na transaction commit and a reflink operation that copied an inline extent\nto an offset beyond the current i_size of the destination node.\n\nThe deadlock happens like this:\n\n1) Task A clones an inline extent from inode X to an offset of inode Y\n that is beyond Y\u0027s current i_size. This means we copied the inline\n extent\u0027s data to a folio of inode Y that is beyond its EOF, using a\n call to copy_inline_to_page();\n\n2) Task B starts a transaction commit and calls\n btrfs_start_delalloc_flush() to flush delalloc;\n\n3) The delalloc flushing sees the new dirty folio of inode Y and when it\n attempts to flush it, it ends up at extent_writepage() and sees that\n the offset of the folio is beyond the i_size of inode Y, so it attempts\n to invalidate the folio by calling folio_invalidate(), which ends up at\n btrfs\u0027 folio invalidate callback - btrfs_invalidate_folio(). There it\n tries to lock the folio\u0027s range in inode Y\u0027s extent io tree, but it\n blocks since it\u0027s currently locked by task A - during a reflink we lock\n the inodes and the source and destination ranges after flushing all\n delalloc and waiting for ordered extent completion - after that we\n don\u0027t expect to have dirty folios in the ranges, the exception is if\n we have to copy an inline extent\u0027s data (because the destination offset\n is not zero);\n\n4) Task A then attempts to start a transaction to update the inode item,\n and then it\u0027s blocked since the current transaction is in the\n TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the\n current transaction to become unblocked (its state \u003e=\n TRANS_STATE_UNBLOCKED).\n\n So task A is waiting for the transaction commit done by task B, and\n the later waiting on the extent lock of inode Y that is currently\n held by task A.\n\nSyzbot recently reported this with the following stack traces:\n\n INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.\n Not tainted syzkaller #0\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000\n Workqueue: writeback wb_workfn (flush-btrfs-46)\n Call Trace:\n \u003cTASK\u003e\n context_switch kernel/sched/core.c:5298 [inline]\n __schedule+0x1553/0x5240 kernel/sched/core.c:6911\n __schedule_loop kernel/sched/core.c:6993 [inline]\n schedule+0x164/0x360 kernel/sched/core.c:7008\n wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]\n btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914\n btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]\n btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704\n extent_writepage fs/btrfs/extent_io.c:1852 [inline]\n extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]\n btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713\n do_writepages+0x32e/0x550 mm/page-writeback.c:2554\n __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750\n writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042\n wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227\n wb_do_writeback fs/fs-writeback.c:2374 [inline]\n wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414\n process_one_work kernel/workqueue.c:3276 [inline]\n process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359\n worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440\n kthread+0x388/0x470 kernel/kthread.c:436\n ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u003c/TASK\u003e\n INFO: task syz.4.64:6910 blocked for more than 143 seconds.\n Not tainted syzkaller #0\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:syz.4.64 state:D stack:22752 pid:6910 tgid:\n---truncated---",
"id": "GHSA-qcjh-44gv-7799",
"modified": "2026-07-23T21:30:35Z",
"published": "2026-06-24T18:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53122"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f0f9c0a368aa1fe078109091322d3b0632d9380"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73be4a08306bb84f4d5d16f62cb80e1543109ffa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a24f0000876b8755cf21972b41632f4d6f3dafb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b48c980b6a7e409050bb3067165db31cc6205e3e"
}
],
"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-QFC7-WQHW-2Q8R
Vulnerability from github – Published: 2025-10-15 15:30 – Updated: 2026-01-23 21:30Under undisclosed traffic conditions along with conditions beyond the attacker's control, hardware systems with a High-Speed Bridge (HSB) may experience a lockup of the HSB.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2025-58153"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-703"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T14:15:52Z",
"severity": "HIGH"
},
"details": "Under undisclosed traffic conditions along with conditions beyond the attacker\u0027s control, hardware systems with a High-Speed Bridge (HSB) may experience a lockup of the HSB.\n\n\u00a0Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-qfc7-wqhw-2q8r",
"modified": "2026-01-23T21:30:39Z",
"published": "2025-10-15T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58153"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000151658"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-QFHJ-Q535-JF9W
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.
Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.
{
"affected": [],
"aliases": [
"CVE-2024-49985"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume\n\nIn case there is any sort of clock controller attached to this I2C bus\ncontroller, for example Versaclock or even an AIC32x4 I2C codec, then\nan I2C transfer triggered from the clock controller clk_ops .prepare\ncallback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.\n\nThis is because the clock controller first grabs the prepare_lock mutex\nand then performs the prepare operation, including its I2C access. The\nI2C access resumes this I2C bus controller via .runtime_resume callback,\nwhich calls clk_prepare_enable(), which attempts to grab the prepare_lock\nmutex again and deadlocks.\n\nSince the clock are already prepared since probe() and unprepared in\nremove(), use simple clk_enable()/clk_disable() calls to enable and\ndisable the clock on runtime suspend and resume, to avoid hitting the\nprepare_lock mutex.",
"id": "GHSA-qfhj-q535-jf9w",
"modified": "2025-11-04T00:31:44Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49985"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/048bbbdbf85e5e00258dfb12f5e368f908801d7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1883cad2cc629ded4a3556c0bbb8b42533ad8764"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22a1f8a5b56ba93d3e8b7a1dafa24e01c8bb48ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/894cd5f5fd9061983445bbd1fa3d81be43095344"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b8bc33ad64192f54142396470cc34ce539a8940"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2024b1a583ab9176c797ea1e5f57baf8d5e2682"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6f1250a4d5773f447740b9fe37b8692105796d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fac3c9f7784e8184c0338e9f0877b81e55d3ef1c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-QFQW-8W5M-FMV4
Vulnerability from github – Published: 2025-01-31 12:33 – Updated: 2025-02-04 18:30In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel
Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues: 1. In SA add section, the should be _bh() variant when marking SA mode. 2. There is not needed flush_workqueue in SA delete routine. It is not needed as at this stage as it is removed from SADB and the running work will be canceled later in SA free.
===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted
charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]
and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 which would create a new lock dependency: (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3}
but this new dependency connects a SOFTIRQ-irq-safe lock: (&x->lock){+.-.}-{3:3}
... which became SOFTIRQ-irq-safe at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60 hrtimer_run_softirq+0x146/0x2e0 handle_softirqs+0x266/0x860 irq_exit_rcu+0x115/0x1a0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 default_idle+0x13/0x20 default_idle_call+0x67/0xa0 do_idle+0x2da/0x320 cpu_startup_entry+0x50/0x60 start_secondary+0x213/0x2a0 common_startup_64+0x129/0x138
to a SOFTIRQ-irq-unsafe lock: (&xa->xa_lock#24){+.+.}-{3:3}
... which became SOFTIRQ-irq-unsafe at: ... lock_acquire+0x1be/0x520 _raw_spin_lock+0x2c/0x40 xa_set_mark+0x70/0x110 mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core] xfrm_dev_state_add+0x3bb/0xd70 xfrm_add_sa+0x2451/0x4a90 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&xa->xa_lock#24); local_irq_disable(); lock(&x->lock); lock(&xa->xa_lock#24); lock(&x->lock);
*** DEADLOCK ***
2 locks held by charon/1337: #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30
the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_alloc_spi+0xc0/0xe60 xfrm_alloc_userspi+0x5f6/0xbc0 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 IN-SOFTIRQ-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60
---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-21674"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-31T12:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel\n\nAttempt to enable IPsec packet offload in tunnel mode in debug kernel\ngenerates the following kernel panic, which is happening due to two\nissues:\n1. In SA add section, the should be _bh() variant when marking SA mode.\n2. There is not needed flush_workqueue in SA delete routine. It is not\nneeded as at this stage as it is removed from SADB and the running work\nwill be canceled later in SA free.\n\n =====================================================\n WARNING: SOFTIRQ-safe -\u003e SOFTIRQ-unsafe lock order detected\n 6.12.0+ #4 Not tainted\n -----------------------------------------------------\n charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:\n ffff88810f365020 (\u0026xa-\u003exa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]\n\n and this task is already holding:\n ffff88813e0f0d48 (\u0026x-\u003elock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n which would create a new lock dependency:\n (\u0026x-\u003elock){+.-.}-{3:3} -\u003e (\u0026xa-\u003exa_lock#24){+.+.}-{3:3}\n\n but this new dependency connects a SOFTIRQ-irq-safe lock:\n (\u0026x-\u003elock){+.-.}-{3:3}\n\n ... which became SOFTIRQ-irq-safe at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_timer_handler+0x91/0xd70\n __hrtimer_run_queues+0x1dd/0xa60\n hrtimer_run_softirq+0x146/0x2e0\n handle_softirqs+0x266/0x860\n irq_exit_rcu+0x115/0x1a0\n sysvec_apic_timer_interrupt+0x6e/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n default_idle+0x13/0x20\n default_idle_call+0x67/0xa0\n do_idle+0x2da/0x320\n cpu_startup_entry+0x50/0x60\n start_secondary+0x213/0x2a0\n common_startup_64+0x129/0x138\n\n to a SOFTIRQ-irq-unsafe lock:\n (\u0026xa-\u003exa_lock#24){+.+.}-{3:3}\n\n ... which became SOFTIRQ-irq-unsafe at:\n ...\n lock_acquire+0x1be/0x520\n _raw_spin_lock+0x2c/0x40\n xa_set_mark+0x70/0x110\n mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]\n xfrm_dev_state_add+0x3bb/0xd70\n xfrm_add_sa+0x2451/0x4a90\n xfrm_user_rcv_msg+0x493/0x880\n netlink_rcv_skb+0x12e/0x380\n xfrm_netlink_rcv+0x6d/0x90\n netlink_unicast+0x42f/0x740\n netlink_sendmsg+0x745/0xbe0\n __sock_sendmsg+0xc5/0x190\n __sys_sendto+0x1fe/0x2c0\n __x64_sys_sendto+0xdc/0x1b0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n other info that might help us debug this:\n\n Possible interrupt unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026xa-\u003exa_lock#24);\n local_irq_disable();\n lock(\u0026x-\u003elock);\n lock(\u0026xa-\u003exa_lock#24);\n \u003cInterrupt\u003e\n lock(\u0026x-\u003elock);\n\n *** DEADLOCK ***\n\n 2 locks held by charon/1337:\n #0: ffffffff87f8f858 (\u0026net-\u003exfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90\n #1: ffff88813e0f0d48 (\u0026x-\u003elock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n\n the dependencies between SOFTIRQ-irq-safe lock and the holding lock:\n -\u003e (\u0026x-\u003elock){+.-.}-{3:3} ops: 29 {\n HARDIRQ-ON-W at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_alloc_spi+0xc0/0xe60\n xfrm_alloc_userspi+0x5f6/0xbc0\n xfrm_user_rcv_msg+0x493/0x880\n netlink_rcv_skb+0x12e/0x380\n xfrm_netlink_rcv+0x6d/0x90\n netlink_unicast+0x42f/0x740\n netlink_sendmsg+0x745/0xbe0\n __sock_sendmsg+0xc5/0x190\n __sys_sendto+0x1fe/0x2c0\n __x64_sys_sendto+0xdc/0x1b0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n IN-SOFTIRQ-W at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_timer_handler+0x91/0xd70\n __hrtimer_run_queues+0x1dd/0xa60\n \n---truncated---",
"id": "GHSA-qfqw-8w5m-fmv4",
"modified": "2025-02-04T18:30:47Z",
"published": "2025-01-31T12:33:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21674"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c3688090f8a1f085230aa839cc63e4a7b977df0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d3d69c070d920fbb146d73dd3899a50f25d0901"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87c4417a902151cfe4363166245a3671a08c256c"
}
],
"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-QGMQ-76M4-C2JV
Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2025-03-25 15:31In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix deadlock during uvc_probe
If uvc_probe() fails, it can end up calling uvc_status_unregister() before uvc_status_init() is called.
Fix this by checking if dev->status is NULL or not in uvc_status_unregister().
{
"affected": [],
"aliases": [
"CVE-2024-58059"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-06T16:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix deadlock during uvc_probe\n\nIf uvc_probe() fails, it can end up calling uvc_status_unregister() before\nuvc_status_init() is called.\n\nFix this by checking if dev-\u003estatus is NULL or not in\nuvc_status_unregister().",
"id": "GHSA-qgmq-76m4-c2jv",
"modified": "2025-03-25T15:31:22Z",
"published": "2025-03-06T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58059"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a67f75c2b5ecf534eab416ce16c11fe780c4f8f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/db577ededf3a18b39567fc1a6209f12a0c4a3c52"
}
],
"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-QHPW-2QGQ-68PX
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 15:31In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix locking usage for tcon fields
We used to use the cifs_tcp_ses_lock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srv_lock, ses_lock and tc_lock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization.
There were still a couple of uses of cifs_tcp_ses_lock to provide tcon fields. In this patch, I've replaced them with tc_lock.
{
"affected": [],
"aliases": [
"CVE-2026-43215"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:41Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix locking usage for tcon fields\n\nWe used to use the cifs_tcp_ses_lock to protect a lot of objects\nthat are not just the server, ses or tcon lists. We later introduced\nsrv_lock, ses_lock and tc_lock to protect fields within the\ncorresponding structs. This was done to provide a more granular\nprotection and avoid unnecessary serialization.\n\nThere were still a couple of uses of cifs_tcp_ses_lock to provide\ntcon fields. In this patch, I\u0027ve replaced them with tc_lock.",
"id": "GHSA-qhpw-2qgq-68px",
"modified": "2026-05-08T15:31:18Z",
"published": "2026-05-06T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43215"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3969db6b22e3d90d8c5f22ac1a7fe0350a94c136"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/601dd3b79769b38d30b693c40afdb2a4b7edf9d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c59eeeeffa1524ef57e173a89a1a3ff539888d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/953953abb66e52c224057ab91e404284fefeab62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96c4af418586ee9a6aab61738644366426e05316"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QJVC-XMQV-CWR9
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change
rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73
but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491
{
"affected": [],
"aliases": [
"CVE-2024-50044"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T20:15:17Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change\n\nrfcomm_sk_state_change attempts to use sock_lock so it must never be\ncalled with it locked but rfcomm_sock_ioctl always attempt to lock it\ncausing the following trace:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted\n------------------------------------------------------\nsyz-executor386/5093 is trying to acquire lock:\nffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]\nffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73\n\nbut task is already holding lock:\nffff88807badfd28 (\u0026d-\u003elock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491",
"id": "GHSA-qjvc-xmqv-cwr9",
"modified": "2026-05-12T15:30:39Z",
"published": "2024-10-21T21:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50044"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08d1914293dae38350b8088980e59fbc699a72fe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38b2d5a57d125e1c17661b8308c0240c4a43b534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/496b2ab0fd10f205e08909a125485fdc98843dbe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cb9807c9b53bf1e5560420d26f319f528b50268"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/869c6ee62ab8f01bf2419e45326642be5c9b670a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b77b3fb12fd483cae7c28648903b1d8a6b275f01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ced98072d3511b232ae1d3347945f35f30c0e303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef44274dae9b0a90d1a97ce8b242a3b8243a7745"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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:L",
"type": "CVSS_V3"
}
]
}
GHSA-QQ67-P454-7JFC
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2025-03-07 18:31In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix another deadlock during RTC update
If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock.
Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-53053"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix another deadlock during RTC update\n\nIf ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm\u0027s usage_count\nis 0, we will enter the runtime suspend callback. However, the runtime\nsuspend callback will wait to flush ufshcd_rtc_work, causing a deadlock.\n\nReplace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the\ndeadlock.",
"id": "GHSA-qq67-p454-7jfc",
"modified": "2025-03-07T18:31:01Z",
"published": "2024-11-19T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53053"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9aa1f0da237d6b16e36e0a0cc9f746d1d78396ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a128cfec44709ab1bd1f01d158569bcb2386f54f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb7e509c4e0197f63717fee54fb41c4990ba8d3a"
}
],
"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-QRPM-P5HJ-4XG3
Vulnerability from github – Published: 2024-06-21 12:31 – Updated: 2025-10-03 15:31In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Lock port->lock when calling uart_handle_cts_change()
uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:
WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]
{
"affected": [],
"aliases": [
"CVE-2024-38634"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-21T11:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: max3100: Lock port-\u003elock when calling uart_handle_cts_change()\n\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0027s taken by explicitly doing\nthat. Without it we got a splat:\n\n WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n ...\n Workqueue: max3100-0 max3100_work [max3100]\n RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n ...\n max3100_handlerx+0xc5/0x110 [max3100]\n max3100_work+0x12a/0x340 [max3100]",
"id": "GHSA-qrpm-p5hj-4xg3",
"modified": "2025-10-03T15:31:13Z",
"published": "2024-06-21T12:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44b38924135d2093e2ec1812969464845dd66dc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/77ab53371a2066fdf9b895246505f5ef5a4b5d47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78dbda51bb4241b88a52d71620f06231a341f9ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8296bb9e5925b6634259c5d4daee88f0cc0884ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/865b30c8661924ee9145f442bf32cea549faa869"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93df2fba6c7dfa9a2f08546ea9a5ca4728758458"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc121e3722a0a2c8f716ef991e5425b180a5fb94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea9b35372b58ac2931bfc1d5bc25e839d1221e30"
},
{
"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-QV39-HG6Q-9R5R
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this:
- File A has inode i_reg and an ea inode i_ea
- getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
-
Then, following three processes running like this:
PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following:
- File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr.
- getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
- Then, following three processes running like this:
PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-45003"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T20:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0027t evict inode under the inode lru traversing context\n\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\n\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\n\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u003ei_ea\n 3. Then, following three processes running like this:\n\n PA PB\n echo 2 \u003e /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // i_reg is added into lru, lru-\u003ei_ea-\u003ei_reg\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n i_ea-\u003ei_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(i_reg)\n spin_unlock(\u0026i_reg-\u003ei_lock)\n spin_unlock(lru_lock)\n rm file A\n i_reg-\u003enlink = 0\n iput(i_reg) // i_reg-\u003enlink is 0, do evict\n ext4_evict_inode\n ext4_xattr_delete_inode\n ext4_xattr_inode_dec_ref_all\n ext4_xattr_inode_iget\n ext4_iget(i_ea-\u003ei_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(i_ea) ----\u2192 AA deadlock\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026i_ea-\u003ei_state)\n\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n deleting process holds BASEHD\u0027s wbuf-\u003eio_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n reclaiming process could try locking BASEHD\u0027s wbuf-\u003eio_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\n\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u003eixa\n 3. Then, following three processes running like this:\n\n PA PB PC\n echo 2 \u003e /proc/sys/vm/drop_caches\n shrink_slab\n prune_dcache_sb\n // ib and ia are added into lru, lru-\u003eixa-\u003eib-\u003eia\n prune_icache_sb\n list_lru_walk_one\n inode_lru_isolate\n ixa-\u003ei_state |= I_FREEING // set inode state\n inode_lru_isolate\n __iget(ib)\n spin_unlock(\u0026ib-\u003ei_lock)\n spin_unlock(lru_lock)\n rm file B\n ib-\u003enlink = 0\n rm file A\n iput(ia)\n ubifs_evict_inode(ia)\n ubifs_jnl_delete_inode(ia)\n ubifs_jnl_write_inode(ia)\n make_reservation(BASEHD) // Lock wbuf-\u003eio_mutex\n ubifs_iget(ixa-\u003ei_ino)\n iget_locked\n find_inode_fast\n __wait_on_freeing_inode(ixa)\n | iput(ib) // ib-\u003enlink is 0, do evict\n | ubifs_evict_inode\n | ubifs_jnl_delete_inode(ib)\n \u2193 ubifs_jnl_write_inode\n ABBA deadlock \u2190-----make_reservation(BASEHD)\n dispose_list // cannot be executed by prune_icache_sb\n wake_up_bit(\u0026ixa-\u003ei_state)\n\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---",
"id": "GHSA-qv39-hg6q-9r5r",
"modified": "2025-11-04T00:31:23Z",
"published": "2024-09-04T21:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45003"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"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:H/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.