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-P7WG-MQFQ-7VVC
Vulnerability from github – Published: 2025-08-19 06:30 – Updated: 2026-01-08 21:30In the Linux kernel, the following vulnerability has been resolved:
net/sched: Restrict conditions for adding duplicating netems to qdisc tree
netem_enqueue's duplication prevention logic breaks when a netem resides in a qdisc tree with other netems - this can lead to a soft lockup and OOM loop in netem_dequeue, as seen in [1]. Ensure that a duplicating netem cannot exist in a tree with other netems.
Previous approaches suggested in discussions in chronological order:
1) Track duplication status or ttl in the sk_buff struct. Considered too specific a use case to extend such a struct, though this would be a resilient fix and address other previous and potential future DOS bugs like the one described in loopy fun [2].
2) Restrict netem_enqueue recursion depth like in act_mirred with a per cpu variable. However, netem_dequeue can call enqueue on its child, and the depth restriction could be bypassed if the child is a netem.
3) Use the same approach as in 2, but add metadata in netem_skb_cb to handle the netem_dequeue case and track a packet's involvement in duplication. This is an overly complex approach, and Jamal notes that the skb cb can be overwritten to circumvent this safeguard.
4) Prevent the addition of a netem to a qdisc tree if its ancestral path contains a netem. However, filters and actions can cause a packet to change paths when re-enqueued to the root from netem duplication, leading us to the current solution: prevent a duplicating netem from inhabiting the same tree as other netems.
[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/ [2] https://lwn.net/Articles/719297/
{
"affected": [],
"aliases": [
"CVE-2025-38553"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-19T06:15:33Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Restrict conditions for adding duplicating netems to qdisc tree\n\nnetem_enqueue\u0027s duplication prevention logic breaks when a netem\nresides in a qdisc tree with other netems - this can lead to a\nsoft lockup and OOM loop in netem_dequeue, as seen in [1].\nEnsure that a duplicating netem cannot exist in a tree with other\nnetems.\n\nPrevious approaches suggested in discussions in chronological order:\n\n1) Track duplication status or ttl in the sk_buff struct. Considered\ntoo specific a use case to extend such a struct, though this would\nbe a resilient fix and address other previous and potential future\nDOS bugs like the one described in loopy fun [2].\n\n2) Restrict netem_enqueue recursion depth like in act_mirred with a\nper cpu variable. However, netem_dequeue can call enqueue on its\nchild, and the depth restriction could be bypassed if the child is a\nnetem.\n\n3) Use the same approach as in 2, but add metadata in netem_skb_cb\nto handle the netem_dequeue case and track a packet\u0027s involvement\nin duplication. This is an overly complex approach, and Jamal\nnotes that the skb cb can be overwritten to circumvent this\nsafeguard.\n\n4) Prevent the addition of a netem to a qdisc tree if its ancestral\npath contains a netem. However, filters and actions can cause a\npacket to change paths when re-enqueued to the root from netem\nduplication, leading us to the current solution: prevent a\nduplicating netem from inhabiting the same tree as other netems.\n\n[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/\n[2] https://lwn.net/Articles/719297/",
"id": "GHSA-p7wg-mqfq-7vvc",
"modified": "2026-01-08T21:30:28Z",
"published": "2025-08-19T06:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38553"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09317dfb681ac5a96fc69bea0c54441cf91b8270"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/103c4e27ec9f5fe53022e46e976abf52c7221baf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/250f8796006c0f2bc638ce545f601d49ae8d528b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/325f5ec67cc0a77f2d0d453445b9857f1cd06c76"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/795cb393e38977aa991e70a9363da0ee734b2114"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad340a4b4adb855b18b3666f26ad65c8968e2deb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cab2809944989889f88a1a8b5cff1c78460c72cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec8e0e3d7adef940cdf9475e2352c0680189d14e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f088b6ebe8797a3f948d2cae47f34bfb45cc6522"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-P823-QQJJ-G5W7
Vulnerability from github – Published: 2023-12-05 18:30 – Updated: 2023-12-05 18:30Dell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information disclosure, information tampering, code execution, denial of service.
{
"affected": [],
"aliases": [
"CVE-2023-44297"
],
"database_specific": {
"cwe_ids": [
"CWE-1234",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-05T16:15:07Z",
"severity": "HIGH"
},
"details": "\nDell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information disclosure, information tampering, code execution, denial of service.\n\n",
"id": "GHSA-p823-qqjj-g5w7",
"modified": "2023-12-05T18:30:23Z",
"published": "2023-12-05T18:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44297"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000220047/dsa-2023-429-security-update-for-dell-16g-poweredge-server-bios-for-a-debug-code-security-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-P865-45GC-8X47
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2023-01-17 21:30A locking issue was discovered in the tty subsystem of the Linux kernel through 5.9.13. drivers/tty/tty_jobctrl.c allows a use-after-free attack against TIOCSPGRP, aka CID-54ffccbf053b.
{
"affected": [],
"aliases": [
"CVE-2020-29661"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-09T17:15:00Z",
"severity": "HIGH"
},
"details": "A locking issue was discovered in the tty subsystem of the Linux kernel through 5.9.13. drivers/tty/tty_jobctrl.c allows a use-after-free attack against TIOCSPGRP, aka CID-54ffccbf053b.",
"id": "GHSA-p865-45gc-8x47",
"modified": "2023-01-17T21:30:20Z",
"published": "2022-05-24T17:35:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29661"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54ffccbf053b5b6ca4f6e45094b942fab92a25fc"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00018.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BOB25SU6XUL4TNP7KB63WNZSYTIYFDPP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MZ7OAKAEFAXQRGBZK4LYUWINCD3D2XCL"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210122-0001"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4843"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/160681/Linux-TIOCSPGRP-Broken-Locking.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/164950/Kernel-Live-Patch-Security-Notice-LSN-0082-1.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/12/10/1"
}
],
"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-P8XF-2W27-6WQX
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2024-11-01 21:31In the Linux kernel, the following vulnerability has been resolved:
af_unix: Clear stale u->oob_skb.
syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support").
The repro basically does the following.
from socket import * from array import array
c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue
c2.close() # done async and unblock recv() c1.close() # done async and trigger GC
A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close().
The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI.
Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost.
from socket import * c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 c1.send(b'world') 5 c2.recv(5) # OOB data is not received b'hell' c2.recv(5) # OOB date is skipped b'world' c2.recv(5, MSG_OOB) # This should return an error b'o'
In the same situation, TCP actually returns -EINVAL for the last recv().
Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv().
To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue.
The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop.
When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket.
With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.
{
"affected": [],
"aliases": [
"CVE-2024-35970"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Clear stale u-\u003eoob_skb.\n\nsyzkaller started to report deadlock of unix_gc_lock after commit\n4090fa373f0e (\"af_unix: Replace garbage collection algorithm.\"), but\nit just uncovers the bug that has been there since commit 314001f0bf92\n(\"af_unix: Add OOB support\").\n\nThe repro basically does the following.\n\n from socket import *\n from array import array\n\n c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)\n c1.sendmsg([b\u0027a\u0027], [(SOL_SOCKET, SCM_RIGHTS, array(\"i\", [c2.fileno()]))], MSG_OOB)\n c2.recv(1) # blocked as no normal data in recv queue\n\n c2.close() # done async and unblock recv()\n c1.close() # done async and trigger GC\n\nA socket sends its file descriptor to itself as OOB data and tries to\nreceive normal data, but finally recv() fails due to async close().\n\nThe problem here is wrong handling of OOB skb in manage_oob(). When\nrecvmsg() is called without MSG_OOB, manage_oob() is called to check\nif the peeked skb is OOB skb. In such a case, manage_oob() pops it\nout of the receive queue but does not clear unix_sock(sk)-\u003eoob_skb.\nThis is wrong in terms of uAPI.\n\nLet\u0027s say we send \"hello\" with MSG_OOB, and \"world\" without MSG_OOB.\nThe \u0027o\u0027 is handled as OOB data. When recv() is called twice without\nMSG_OOB, the OOB data should be lost.\n\n \u003e\u003e\u003e from socket import *\n \u003e\u003e\u003e c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)\n \u003e\u003e\u003e c1.send(b\u0027hello\u0027, MSG_OOB) # \u0027o\u0027 is OOB data\n 5\n \u003e\u003e\u003e c1.send(b\u0027world\u0027)\n 5\n \u003e\u003e\u003e c2.recv(5) # OOB data is not received\n b\u0027hell\u0027\n \u003e\u003e\u003e c2.recv(5) # OOB date is skipped\n b\u0027world\u0027\n \u003e\u003e\u003e c2.recv(5, MSG_OOB) # This should return an error\n b\u0027o\u0027\n\nIn the same situation, TCP actually returns -EINVAL for the last\nrecv().\n\nAlso, if we do not clear unix_sk(sk)-\u003eoob_skb, unix_poll() always set\nEPOLLPRI even though the data has passed through by previous recv().\n\nTo avoid these issues, we must clear unix_sk(sk)-\u003eoob_skb when dequeuing\nit from recv queue.\n\nThe reason why the old GC did not trigger the deadlock is because the\nold GC relied on the receive queue to detect the loop.\n\nWhen it is triggered, the socket with OOB data is marked as GC candidate\nbecause file refcount == inflight count (1). However, after traversing\nall inflight sockets, the socket still has a positive inflight count (1),\nthus the socket is excluded from candidates. Then, the old GC lose the\nchance to garbage-collect the socket.\n\nWith the old GC, the repro continues to create true garbage that will\nnever be freed nor detected by kmemleak as it\u0027s linked to the global\ninflight list. That\u0027s why we couldn\u0027t even notice the issue.",
"id": "GHSA-p8xf-2w27-6wqx",
"modified": "2024-11-01T21:31:46Z",
"published": "2024-05-20T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35970"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-P8XQ-M5G2-CVRC
Vulnerability from github – Published: 2024-05-01 15:30 – Updated: 2024-12-23 21:30In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt
The loop inside nfs_netfs_issue_read() currently does not disable interrupts while iterating through pages in the xarray to submit for NFS read. This is not safe though since after taking xa_lock, another page in the mapping could be processed for writeback inside an interrupt, and deadlock can occur. The fix is simple and clean if we use xa_for_each_range(), which handles the iteration with RCU while reducing code complexity.
The problem is easily reproduced with the following test: mount -o vers=3,fsc 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1 echo 3 > /proc/sys/vm/drop_caches dd if=/mnt/nfs/file1.bin of=/dev/null umount /mnt/nfs
On the console with a lockdep-enabled kernel a message similar to the following will be seen:
================================ WARNING: inconsistent lock state 6.7.0-lockdbg+ #10 Not tainted
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888127baa598 (&xa->xa_lock#4){+.?.}-{3:3}, at: nfs_netfs_issue_read+0x1b2/0x4b0 [nfs] {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x144/0x380 _raw_spin_lock_irqsave+0x4e/0xa0 __folio_end_writeback+0x17e/0x5c0 folio_end_writeback+0x93/0x1b0 iomap_finish_ioend+0xeb/0x6a0 blk_update_request+0x204/0x7f0 blk_mq_end_request+0x30/0x1c0 blk_complete_reqs+0x7e/0xa0 __do_softirq+0x113/0x544 __irq_exit_rcu+0xfe/0x120 irq_exit_rcu+0xe/0x20 sysvec_call_function_single+0x6f/0x90 asm_sysvec_call_function_single+0x1a/0x20 pv_native_safe_halt+0xf/0x20 default_idle+0x9/0x20 default_idle_call+0x67/0xa0 do_idle+0x2b5/0x300 cpu_startup_entry+0x34/0x40 start_secondary+0x19d/0x1c0 secondary_startup_64_no_verify+0x18f/0x19b irq event stamp: 176891 hardirqs last enabled at (176891): [] _raw_spin_unlock_irqrestore+0x44/0x60 hardirqs last disabled at (176890): [] _raw_spin_lock_irqsave+0x79/0xa0 softirqs last enabled at (176646): [] __irq_exit_rcu+0xfe/0x120 softirqs last disabled at (176633): [] __irq_exit_rcu+0xfe/0x120
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&xa->xa_lock#4); lock(&xa->xa_lock#4);
*** DEADLOCK ***
2 locks held by test5/1708: #0: ffff888127baa498 (&sb->s_type->i_mutex_key#22){++++}-{4:4}, at: nfs_start_io_read+0x28/0x90 [nfs] #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at: page_cache_ra_unbounded+0xa4/0x280
stack backtrace: CPU: 6 PID: 1708 Comm: test5 Kdump: loaded Not tainted 6.7.0-lockdbg+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Call Trace: dump_stack_lvl+0x5b/0x90 mark_lock+0xb3f/0xd20 __lock_acquire+0x77b/0x3360 _raw_spin_lock+0x34/0x80 nfs_netfs_issue_read+0x1b2/0x4b0 [nfs] netfs_begin_read+0x77f/0x980 [netfs] nfs_netfs_readahead+0x45/0x60 [nfs] nfs_readahead+0x323/0x5a0 [nfs] read_pages+0xf3/0x5c0 page_cache_ra_unbounded+0x1c8/0x280 filemap_get_pages+0x38c/0xae0 filemap_read+0x206/0x5e0 nfs_file_read+0xb7/0x140 [nfs] vfs_read+0x2a9/0x460 ksys_read+0xb7/0x140
{
"affected": [],
"aliases": [
"CVE-2024-27031"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T13:15:49Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix nfs_netfs_issue_read() xarray locking for writeback interrupt\n\nThe loop inside nfs_netfs_issue_read() currently does not disable\ninterrupts while iterating through pages in the xarray to submit\nfor NFS read. This is not safe though since after taking xa_lock,\nanother page in the mapping could be processed for writeback inside\nan interrupt, and deadlock can occur. The fix is simple and clean\nif we use xa_for_each_range(), which handles the iteration with RCU\nwhile reducing code complexity.\n\nThe problem is easily reproduced with the following test:\n mount -o vers=3,fsc 127.0.0.1:/export /mnt/nfs\n dd if=/dev/zero of=/mnt/nfs/file1.bin bs=4096 count=1\n echo 3 \u003e /proc/sys/vm/drop_caches\n dd if=/mnt/nfs/file1.bin of=/dev/null\n umount /mnt/nfs\n\nOn the console with a lockdep-enabled kernel a message similar to\nthe following will be seen:\n\n ================================\n WARNING: inconsistent lock state\n 6.7.0-lockdbg+ #10 Not tainted\n --------------------------------\n inconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-W} usage.\n test5/1708 [HC0[0]:SC0[0]:HE1:SE1] takes:\n ffff888127baa598 (\u0026xa-\u003exa_lock#4){+.?.}-{3:3}, at:\nnfs_netfs_issue_read+0x1b2/0x4b0 [nfs]\n {IN-SOFTIRQ-W} state was registered at:\n lock_acquire+0x144/0x380\n _raw_spin_lock_irqsave+0x4e/0xa0\n __folio_end_writeback+0x17e/0x5c0\n folio_end_writeback+0x93/0x1b0\n iomap_finish_ioend+0xeb/0x6a0\n blk_update_request+0x204/0x7f0\n blk_mq_end_request+0x30/0x1c0\n blk_complete_reqs+0x7e/0xa0\n __do_softirq+0x113/0x544\n __irq_exit_rcu+0xfe/0x120\n irq_exit_rcu+0xe/0x20\n sysvec_call_function_single+0x6f/0x90\n asm_sysvec_call_function_single+0x1a/0x20\n pv_native_safe_halt+0xf/0x20\n default_idle+0x9/0x20\n default_idle_call+0x67/0xa0\n do_idle+0x2b5/0x300\n cpu_startup_entry+0x34/0x40\n start_secondary+0x19d/0x1c0\n secondary_startup_64_no_verify+0x18f/0x19b\n irq event stamp: 176891\n hardirqs last enabled at (176891): [\u003cffffffffa67a0be4\u003e]\n_raw_spin_unlock_irqrestore+0x44/0x60\n hardirqs last disabled at (176890): [\u003cffffffffa67a0899\u003e]\n_raw_spin_lock_irqsave+0x79/0xa0\n softirqs last enabled at (176646): [\u003cffffffffa515d91e\u003e]\n__irq_exit_rcu+0xfe/0x120\n softirqs last disabled at (176633): [\u003cffffffffa515d91e\u003e]\n__irq_exit_rcu+0xfe/0x120\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026xa-\u003exa_lock#4);\n \u003cInterrupt\u003e\n lock(\u0026xa-\u003exa_lock#4);\n\n *** DEADLOCK ***\n\n 2 locks held by test5/1708:\n #0: ffff888127baa498 (\u0026sb-\u003es_type-\u003ei_mutex_key#22){++++}-{4:4}, at:\n nfs_start_io_read+0x28/0x90 [nfs]\n #1: ffff888127baa650 (mapping.invalidate_lock#3){.+.+}-{4:4}, at:\n page_cache_ra_unbounded+0xa4/0x280\n\n stack backtrace:\n CPU: 6 PID: 1708 Comm: test5 Kdump: loaded Not tainted 6.7.0-lockdbg+\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39\n04/01/2014\n Call Trace:\n dump_stack_lvl+0x5b/0x90\n mark_lock+0xb3f/0xd20\n __lock_acquire+0x77b/0x3360\n _raw_spin_lock+0x34/0x80\n nfs_netfs_issue_read+0x1b2/0x4b0 [nfs]\n netfs_begin_read+0x77f/0x980 [netfs]\n nfs_netfs_readahead+0x45/0x60 [nfs]\n nfs_readahead+0x323/0x5a0 [nfs]\n read_pages+0xf3/0x5c0\n page_cache_ra_unbounded+0x1c8/0x280\n filemap_get_pages+0x38c/0xae0\n filemap_read+0x206/0x5e0\n nfs_file_read+0xb7/0x140 [nfs]\n vfs_read+0x2a9/0x460\n ksys_read+0xb7/0x140",
"id": "GHSA-p8xq-m5g2-cvrc",
"modified": "2024-12-23T21:30:50Z",
"published": "2024-05-01T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27031"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a2e5977cecd3cde6a0e3e86b7b914d00240e5dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8df1678c021ffeb20ef8a203bd9413f3ed9b0e9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad27382f8495f8ef6d2c66c413d756bfd13c0598"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd5860ab6341506004219b080aea40213b299d2e"
}
],
"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-P9J3-R5PW-645F
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-02-27 15:31In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix circular locking dependency
The rule inside kvm enforces that the vcpu->mutex is taken inside kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data.
{
"affected": [],
"aliases": [
"CVE-2024-26691"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T15:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Fix circular locking dependency\n\nThe rule inside kvm enforces that the vcpu-\u003emutex is taken *inside*\nkvm-\u003elock. The rule is violated by the pkvm_create_hyp_vm() which acquires\nthe kvm-\u003elock while already holding the vcpu-\u003emutex lock from\nkvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by\nprotecting the hyp vm handle with the config_lock, much like we already\ndo for other forms of VM-scoped data.",
"id": "GHSA-p9j3-r5pw-645f",
"modified": "2025-02-27T15:31:49Z",
"published": "2024-04-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26691"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228"
}
],
"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-PF4F-8WPM-5VH2
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock
There are multiple places from where the recovery work gets scheduled asynchronously. Also, there are multiple places where the caller waits synchronously for the recovery to be completed. One such place is during the PM shutdown() callback.
If the device is not alive during recovery_work, it will try to reset the device using pci_reset_function(). This function internally will take the device_lock() first before resetting the device. By this time, if the lock has already been acquired, then recovery_work will get stalled while waiting for the lock. And if the lock was already acquired by the caller which waits for the recovery_work to be completed, it will lead to deadlock.
This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver's shutdown() callback while holding the device_lock() leading to deadlock.
And this deadlock scenario can occur on other paths as well, like during the PM suspend() callback, where the driver core would hold the device_lock() before calling driver's suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD.
So to fix both issues, use pci_try_reset_function() in recovery_work. This function first checks for the availability of the device_lock() before trying to reset the device. If the lock is available, it will acquire it and reset the device. Otherwise, it will return -EAGAIN. If that happens, recovery_work will fail with the error message "Recovery failed" as not much could be done.
{
"affected": [],
"aliases": [
"CVE-2025-21951"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock\n\nThere are multiple places from where the recovery work gets scheduled\nasynchronously. Also, there are multiple places where the caller waits\nsynchronously for the recovery to be completed. One such place is during\nthe PM shutdown() callback.\n\nIf the device is not alive during recovery_work, it will try to reset the\ndevice using pci_reset_function(). This function internally will take the\ndevice_lock() first before resetting the device. By this time, if the lock\nhas already been acquired, then recovery_work will get stalled while\nwaiting for the lock. And if the lock was already acquired by the caller\nwhich waits for the recovery_work to be completed, it will lead to\ndeadlock.\n\nThis is what happened on the X1E80100 CRD device when the device died\nbefore shutdown() callback. Driver core calls the driver\u0027s shutdown()\ncallback while holding the device_lock() leading to deadlock.\n\nAnd this deadlock scenario can occur on other paths as well, like during\nthe PM suspend() callback, where the driver core would hold the\ndevice_lock() before calling driver\u0027s suspend() callback. And if the\nrecovery_work was already started, it could lead to deadlock. This is also\nobserved on the X1E80100 CRD.\n\nSo to fix both issues, use pci_try_reset_function() in recovery_work. This\nfunction first checks for the availability of the device_lock() before\ntrying to reset the device. If the lock is available, it will acquire it\nand reset the device. Otherwise, it will return -EAGAIN. If that happens,\nrecovery_work will fail with the error message \"Recovery failed\" as not\nmuch could be done.",
"id": "GHSA-pf4f-8wpm-5vh2",
"modified": "2025-11-03T21:33:25Z",
"published": "2025-04-01T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21951"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f9eb7078bc6b5fb5cbfbcb37c4bc01685332b95"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62505657475c245c9cd46e42ac01026d1e61f027"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7746f3bb8917fccb4571a576f3837d80fc513054"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a5ffadd54fe2662f5c99cdccf30144d060376f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/985d3cf56d8745ca637deee273929e01df449f85"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a321d163de3d8aa38a6449ab2becf4b1581aed96"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-PF8W-93QV-JM8P
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2025-11-25 21:32In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix lockdep warning during rmmod
The commit under the Fixes tag added a netdev_assert_locked() in bnxt_free_ntp_fltrs(). The lock should be held during normal run-time but the assert will be triggered (see below) during bnxt_remove_one() which should not need the lock. The netdev is already unregistered by then. Fix it by calling netdev_assert_locked_or_invisible() which will not assert if the netdev is unregistered.
WARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re] CPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary) Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en] Code: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff <0f> 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa92082387da0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001 RDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf RBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3 R10: 000000008100009f R11: 0000000000000001 R12: 0000000000000001 R13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100 FS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0 Call Trace: bnxt_remove_one+0x57/0x180 [bnxt_en] pci_device_remove+0x39/0xc0 device_release_driver_internal+0xa5/0x130 driver_detach+0x42/0x90 bus_remove_driver+0x61/0xc0 pci_unregister_driver+0x38/0x90 bnxt_exit+0xc/0x7d0 [bnxt_en]
{
"affected": [],
"aliases": [
"CVE-2025-39769"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix lockdep warning during rmmod\n\nThe commit under the Fixes tag added a netdev_assert_locked() in\nbnxt_free_ntp_fltrs(). The lock should be held during normal run-time\nbut the assert will be triggered (see below) during bnxt_remove_one()\nwhich should not need the lock. The netdev is already unregistered by\nthen. Fix it by calling netdev_assert_locked_or_invisible() which will\nnot assert if the netdev is unregistered.\n\nWARNING: CPU: 5 PID: 2241 at ./include/net/netdev_lock.h:17 bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]\nModules linked in: rpcrdma rdma_cm iw_cm ib_cm configfs ib_core bnxt_en(-) bridge stp llc x86_pkg_temp_thermal xfs tg3 [last unloaded: bnxt_re]\nCPU: 5 UID: 0 PID: 2241 Comm: rmmod Tainted: G S W 6.16.0 #2 PREEMPT(voluntary)\nTainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN\nHardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017\nRIP: 0010:bnxt_free_ntp_fltrs+0xf8/0x100 [bnxt_en]\nCode: 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 8b 47 60 be ff ff ff ff 48 8d b8 28 0c 00 00 e8 d0 cf 41 c3 85 c0 0f 85 2e ff ff ff \u003c0f\u003e 0b e9 27 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90\nRSP: 0018:ffffa92082387da0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff9e5b593d8000 RCX: 0000000000000001\nRDX: 0000000000000001 RSI: ffffffff83dc9a70 RDI: ffffffff83e1a1cf\nRBP: ffff9e5b593d8c80 R08: 0000000000000000 R09: ffffffff8373a2b3\nR10: 000000008100009f R11: 0000000000000001 R12: 0000000000000001\nR13: ffffffffc01c4478 R14: dead000000000122 R15: dead000000000100\nFS: 00007f3a8a52c740(0000) GS:ffff9e631ad1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055bb289419c8 CR3: 000000011274e001 CR4: 00000000003706f0\nCall Trace:\n \u003cTASK\u003e\n bnxt_remove_one+0x57/0x180 [bnxt_en]\n pci_device_remove+0x39/0xc0\n device_release_driver_internal+0xa5/0x130\n driver_detach+0x42/0x90\n bus_remove_driver+0x61/0xc0\n pci_unregister_driver+0x38/0x90\n bnxt_exit+0xc/0x7d0 [bnxt_en]",
"id": "GHSA-pf8w-93qv-jm8p",
"modified": "2025-11-25T21:32:04Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39769"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4611d88a37cfc18cbabc6978aaf7325d1ae3f53a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5885d39dce879fbbc953f40e19adb60c29802302"
}
],
"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-PFF6-G7WW-P3V3
Vulnerability from github – Published: 2026-03-29 15:30 – Updated: 2026-04-24 15:32In the Linux kernel, the following vulnerability has been resolved:
rust_binder: call set_notification_done() without proc lock
Consider the following sequence of events on a death listener: 1. The remote process dies and sends a BR_DEAD_BINDER message. 2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command. 3. The local process then invokes the BC_DEAD_BINDER_DONE. Then, the kernel will reply to the BC_DEAD_BINDER_DONE command with a BR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().
However, this can result in a deadlock if the current thread is not a looper. This is because dead_binder_done() still holds the proc lock during set_notification_done(), which called push_work_if_looper(). Normally, push_work_if_looper() takes the thread lock, which is fine to take under the proc lock. But if the current thread is not a looper, then it falls back to delivering the reply to the process work queue, which involves taking the proc lock. Since the proc lock is already held, this is a deadlock.
Fix this by releasing the proc lock during set_notification_done(). It was not intentional that it was held during that function to begin with.
I don't think this ever happens in Android because BC_DEAD_BINDER_DONE is only invoked in response to BR_DEAD_BINDER messages, and the kernel always delivers BR_DEAD_BINDER to a looper. So there's no scenario where Android userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.
{
"affected": [],
"aliases": [
"CVE-2026-23400"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-29T13:16:58Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: call set_notification_done() without proc lock\n\nConsider the following sequence of events on a death listener:\n1. The remote process dies and sends a BR_DEAD_BINDER message.\n2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command.\n3. The local process then invokes the BC_DEAD_BINDER_DONE.\nThen, the kernel will reply to the BC_DEAD_BINDER_DONE command with a\nBR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().\n\nHowever, this can result in a deadlock if the current thread is not a\nlooper. This is because dead_binder_done() still holds the proc lock\nduring set_notification_done(), which called push_work_if_looper().\nNormally, push_work_if_looper() takes the thread lock, which is fine to\ntake under the proc lock. But if the current thread is not a looper,\nthen it falls back to delivering the reply to the process work queue,\nwhich involves taking the proc lock. Since the proc lock is already\nheld, this is a deadlock.\n\nFix this by releasing the proc lock during set_notification_done(). It\nwas not intentional that it was held during that function to begin with.\n\nI don\u0027t think this ever happens in Android because BC_DEAD_BINDER_DONE\nis only invoked in response to BR_DEAD_BINDER messages, and the kernel\nalways delivers BR_DEAD_BINDER to a looper. So there\u0027s no scenario where\nAndroid userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.",
"id": "GHSA-pff6-g7ww-p3v3",
"modified": "2026-04-24T15:32:19Z",
"published": "2026-03-29T15:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23400"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e303f0febb65a434040774b793ba8356698802b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3be72099067d2cd4a0e089696f19780f75b2b88a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd109e3442817bc03ad1f3ffd541092f8c428141"
}
],
"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-PGJM-RQQP-M93M
Vulnerability from github – Published: 2025-02-27 21:32 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
tty: xilinx_uartps: split sysrq handling
lockdep detects the following circular locking dependency:
CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()
The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock.
Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.
{
"affected": [],
"aliases": [
"CVE-2025-21820"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T20:16:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: xilinx_uartps: split sysrq handling\n\nlockdep detects the following circular locking dependency:\n\nCPU 0 CPU 1\n========================== ============================\ncdns_uart_isr() printk()\n uart_port_lock(port) console_lock()\n\t\t\t cdns_uart_console_write()\n if (!port-\u003esysrq)\n uart_port_lock(port)\n uart_handle_break()\n port-\u003esysrq = ...\n uart_handle_sysrq_char()\n printk()\n console_lock()\n\nThe fixed commit attempts to avoid this situation by only taking the\nport lock in cdns_uart_console_write if port-\u003esysrq unset. However, if\n(as shown above) cdns_uart_console_write runs before port-\u003esysrq is set,\nthen it will try to take the port lock anyway. This may result in a\ndeadlock.\n\nFix this by splitting sysrq handling into two parts. We use the prepare\nhelper under the port lock and defer handling until we release the lock.",
"id": "GHSA-pgjm-rqqp-m93m",
"modified": "2025-11-03T21:33:02Z",
"published": "2025-02-27T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21820"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4410dba9807a17a93f649a9f5870ceaf30a675a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ea0e7b3d7b8f2f0fc9db491ff22a0abe120801c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b88a7c4584ba67267a051069b8abe44fc9595b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b06f388994500297bb91be60ffaf6825ecfd2afe"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de5bd24197bd9ee37ec1e379a3d882bbd15c5065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e22a97700901ba5e8bf8db68056a0d50f9440cae"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.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"
}
]
}
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.