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-P5FC-WW5C-RRV7
Vulnerability from github – Published: 2022-05-02 03:23 – Updated: 2024-02-15 21:31net/ipv4/udp.c in the Linux kernel before 2.6.29.1 performs an unlocking step in certain incorrect circumstances, which allows local users to cause a denial of service (panic) by reading zero bytes from the /proc/net/udp file and unspecified other files, related to the "udp seq_file infrastructure."
{
"affected": [],
"aliases": [
"CVE-2009-1243"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-04-06T14:30:00Z",
"severity": "LOW"
},
"details": "net/ipv4/udp.c in the Linux kernel before 2.6.29.1 performs an unlocking step in certain incorrect circumstances, which allows local users to cause a denial of service (panic) by reading zero bytes from the /proc/net/udp file and unspecified other files, related to the \"udp seq_file infrastructure.\"",
"id": "GHSA-p5fc-ww5c-rrv7",
"modified": "2024-02-15T21:31:23Z",
"published": "2022-05-02T03:23:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1243"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/49595"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=30842f2989aacfaba3ccb39829b3417be9313dbe"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=30842f2989aacfaba3ccb39829b3417be9313dbe"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2009/04/01/4"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/34478"
},
{
"type": "WEB",
"url": "http://vigilance.fr/vulnerability/Linux-kernel-denial-of-service-via-proc-net-udp-8586"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.29.1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/34329"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/0924"
}
],
"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-P6XG-JWXF-89CH
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2025-01-14 15:30In the Linux kernel, the following vulnerability has been resolved:
pds_core: Fix pdsc_check_pci_health function to use work thread
When the driver notices fw_status == 0xff it tries to perform a PCI reset on itself via pci_reset_function() in the context of the driver's health thread. However, pdsc_reset_prepare calls pdsc_stop_health_thread(), which attempts to stop/flush the health thread. This results in a deadlock because the stop/flush will never complete since the driver called pci_reset_function() from the health thread context. Fix by changing the pdsc_check_pci_health_function() to queue a newly introduced pdsc_pci_reset_thread() on the pdsc's work queue.
Unloading the driver in the fw_down/dead state uncovered another issue, which can be seen in the following trace:
WARNING: CPU: 51 PID: 6914 at kernel/workqueue.c:1450 __queue_work+0x358/0x440 [...] RIP: 0010:__queue_work+0x358/0x440 [...] Call Trace: ? __warn+0x85/0x140 ? __queue_work+0x358/0x440 ? report_bug+0xfc/0x1e0 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __queue_work+0x358/0x440 queue_work_on+0x28/0x30 pdsc_devcmd_locked+0x96/0xe0 [pds_core] pdsc_devcmd_reset+0x71/0xb0 [pds_core] pdsc_teardown+0x51/0xe0 [pds_core] pdsc_remove+0x106/0x200 [pds_core] pci_device_remove+0x37/0xc0 device_release_driver_internal+0xae/0x140 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xa0 pdsc_cleanup_module+0x10/0x780 [pds_core] __x64_sys_delete_module+0x142/0x2b0 ? syscall_trace_enter.isra.18+0x126/0x1a0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7fbd9d03a14b [...]
Fix this by preventing the devcmd reset if the FW is not running.
{
"affected": [],
"aliases": [
"CVE-2024-35968"
],
"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\npds_core: Fix pdsc_check_pci_health function to use work thread\n\nWhen the driver notices fw_status == 0xff it tries to perform a PCI\nreset on itself via pci_reset_function() in the context of the driver\u0027s\nhealth thread. However, pdsc_reset_prepare calls\npdsc_stop_health_thread(), which attempts to stop/flush the health\nthread. This results in a deadlock because the stop/flush will never\ncomplete since the driver called pci_reset_function() from the health\nthread context. Fix by changing the pdsc_check_pci_health_function()\nto queue a newly introduced pdsc_pci_reset_thread() on the pdsc\u0027s\nwork queue.\n\nUnloading the driver in the fw_down/dead state uncovered another issue,\nwhich can be seen in the following trace:\n\nWARNING: CPU: 51 PID: 6914 at kernel/workqueue.c:1450 __queue_work+0x358/0x440\n[...]\nRIP: 0010:__queue_work+0x358/0x440\n[...]\nCall Trace:\n \u003cTASK\u003e\n ? __warn+0x85/0x140\n ? __queue_work+0x358/0x440\n ? report_bug+0xfc/0x1e0\n ? handle_bug+0x3f/0x70\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? __queue_work+0x358/0x440\n queue_work_on+0x28/0x30\n pdsc_devcmd_locked+0x96/0xe0 [pds_core]\n pdsc_devcmd_reset+0x71/0xb0 [pds_core]\n pdsc_teardown+0x51/0xe0 [pds_core]\n pdsc_remove+0x106/0x200 [pds_core]\n pci_device_remove+0x37/0xc0\n device_release_driver_internal+0xae/0x140\n driver_detach+0x48/0x90\n bus_remove_driver+0x6d/0xf0\n pci_unregister_driver+0x2e/0xa0\n pdsc_cleanup_module+0x10/0x780 [pds_core]\n __x64_sys_delete_module+0x142/0x2b0\n ? syscall_trace_enter.isra.18+0x126/0x1a0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7fbd9d03a14b\n[...]\n\nFix this by preventing the devcmd reset if the FW is not running.",
"id": "GHSA-p6xg-jwxf-89ch",
"modified": "2025-01-14T15:30:50Z",
"published": "2024-05-20T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35968"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38407914d48273d7f8ab765b9243658afe1c3ab6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81665adf25d28a00a986533f1d3a5df76b79cad9"
}
],
"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-P72G-8563-4JG8
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2022-05-24 16:45A vulnerability in the Remote Package Manager (RPM) subsystem of Cisco NX-OS Software could allow an authenticated, local attacker with administrator credentials to leverage a time-of-check, time-of-use (TOCTOU) race condition to corrupt local variables, which could lead to arbitrary command injection. The vulnerability is due to the lack of a proper locking mechanism on critical variables that need to stay static until used. An attacker could exploit this vulnerability by authenticating to an affected device and issuing a set of RPM-related CLI commands. A successful exploit could allow the attacker to perform arbitrary command injection. The attacker would need administrator credentials for the targeted device.
{
"affected": [],
"aliases": [
"CVE-2019-1732"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-15T17:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Remote Package Manager (RPM) subsystem of Cisco NX-OS Software could allow an authenticated, local attacker with administrator credentials to leverage a time-of-check, time-of-use (TOCTOU) race condition to corrupt local variables, which could lead to arbitrary command injection. The vulnerability is due to the lack of a proper locking mechanism on critical variables that need to stay static until used. An attacker could exploit this vulnerability by authenticating to an affected device and issuing a set of RPM-related CLI commands. A successful exploit could allow the attacker to perform arbitrary command injection. The attacker would need administrator credentials for the targeted device.",
"id": "GHSA-p72g-8563-4jg8",
"modified": "2022-05-24T16:45:43Z",
"published": "2022-05-24T16:45:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1732"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-nxos-rpm-injec"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108361"
}
],
"schema_version": "1.4.0",
"severity": []
}
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"
}
]
}
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.