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.
755 vulnerabilities reference this CWE, most recent first.
GHSA-HJGX-24CQ-764X
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-19 18:31In the Linux kernel, the following vulnerability has been resolved:
procfs: avoid fetching build ID while holding VMA lock
Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot:
-> #1 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0xed/0x170 _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}: __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0 __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(&mm->mmap_lock); lock(&sb->s_type->i_mutex_key#8); lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8);
*** DEADLOCK ***
This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent:
777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")
To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal build_id_parse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant build_id_parse_file() that expects file passed directly.
[akpm@linux-foundation.org: fix up kerneldoc]
{
"affected": [],
"aliases": [
"CVE-2026-23199"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T17:15:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nprocfs: avoid fetching build ID while holding VMA lock\n\nFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock\nor per-VMA lock, whichever was used to lock VMA under question, to avoid\ndeadlock reported by syzbot:\n\n -\u003e #1 (\u0026mm-\u003emmap_lock){++++}-{4:4}:\n __might_fault+0xed/0x170\n _copy_to_iter+0x118/0x1720\n copy_page_to_iter+0x12d/0x1e0\n filemap_read+0x720/0x10a0\n blkdev_read_iter+0x2b5/0x4e0\n vfs_read+0x7f4/0xae0\n ksys_read+0x12a/0x250\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n -\u003e #0 (\u0026sb-\u003es_type-\u003ei_mutex_key#8){++++}-{4:4}:\n __lock_acquire+0x1509/0x26d0\n lock_acquire+0x185/0x340\n down_read+0x98/0x490\n blkdev_read_iter+0x2a7/0x4e0\n __kernel_read+0x39a/0xa90\n freader_fetch+0x1d5/0xa80\n __build_id_parse.isra.0+0xea/0x6a0\n do_procmap_query+0xd75/0x1050\n procfs_procmap_ioctl+0x7a/0xb0\n __x64_sys_ioctl+0x18e/0x210\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n other info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n rlock(\u0026mm-\u003emmap_lock);\n lock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n lock(\u0026mm-\u003emmap_lock);\n rlock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n\n *** DEADLOCK ***\n\nThis seems to be exacerbated (as we haven\u0027t seen these syzbot reports\nbefore that) by the recent:\n\n\t777a8560fd29 (\"lib/buildid: use __kernel_read() for sleepable context\")\n\nTo make this safe, we need to grab file refcount while VMA is still locked, but\nother than that everything is pretty straightforward. Internal build_id_parse()\nAPI assumes VMA is passed, but it only needs the underlying file reference, so\njust add another variant build_id_parse_file() that expects file passed\ndirectly.\n\n[akpm@linux-foundation.org: fix up kerneldoc]",
"id": "GHSA-hjgx-24cq-764x",
"modified": "2026-03-19T18:31:14Z",
"published": "2026-02-14T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23199"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08"
}
],
"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-HJJF-XJVR-567J
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-19 18:31In the Linux kernel, the following vulnerability has been resolved:
net: usb: r8152: fix resume reset deadlock
rtl8152 can trigger device reset during reset which potentially can result in a deadlock:
**** DPM device timeout after 10 seconds; 15 seconds until panic **** Call Trace: schedule+0x483/0x1370 schedule_preempt_disabled+0x15/0x30 __mutex_lock_common+0x1fd/0x470 __rtl8152_set_mac_address+0x80/0x1f0 dev_set_mac_address+0x7f/0x150 rtl8152_post_reset+0x72/0x150 usb_reset_device+0x1d0/0x220 rtl8152_resume+0x99/0xc0 usb_resume_interface+0x3e/0xc0 usb_resume_both+0x104/0x150 usb_resume+0x22/0x110
The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again.
Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutex_lock() deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-23188"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T17:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: r8152: fix resume reset deadlock\n\nrtl8152 can trigger device reset during reset which\npotentially can result in a deadlock:\n\n **** DPM device timeout after 10 seconds; 15 seconds until panic ****\n Call Trace:\n \u003cTASK\u003e\n schedule+0x483/0x1370\n schedule_preempt_disabled+0x15/0x30\n __mutex_lock_common+0x1fd/0x470\n __rtl8152_set_mac_address+0x80/0x1f0\n dev_set_mac_address+0x7f/0x150\n rtl8152_post_reset+0x72/0x150\n usb_reset_device+0x1d0/0x220\n rtl8152_resume+0x99/0xc0\n usb_resume_interface+0x3e/0xc0\n usb_resume_both+0x104/0x150\n usb_resume+0x22/0x110\n\nThe problem is that rtl8152 resume calls reset under\ntp-\u003econtrol mutex while reset basically re-enters rtl8152\nand attempts to acquire the same tp-\u003econtrol lock once\nagain.\n\nReset INACCESSIBLE device outside of tp-\u003econtrol mutex\nscope to avoid recursive mutex_lock() deadlock.",
"id": "GHSA-hjjf-xjvr-567j",
"modified": "2026-03-19T18:31:14Z",
"published": "2026-02-14T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23188"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b2efc593dca99d8e8e6f6d6c7ccd9a972679702"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61c8091b7937f91f9bc0b7f6b578de270fe35dc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d06bc83a5ae8777a5f7a81c32dd75b8d9b2fe04"
}
],
"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-HMGJ-4596-MMPR
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-27 21:31In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.
{
"affected": [],
"aliases": [
"CVE-2024-38597"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\n\nErhard reports netpoll warnings from sungem:\n\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\n\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0027t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0027t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.",
"id": "GHSA-hmgj-4596-mmpr",
"modified": "2024-08-27T21:31:13Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289"
}
],
"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-HP4X-9RGH-5PGM
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-10-15 03:35In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix deadlock during netdev reset with active connections
Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-31565"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix deadlock during netdev reset with active connections\n\nResolve deadlock that occurs when user executes netdev reset while RDMA\napplications (e.g., rping) are active. The netdev reset causes ice\ndriver to remove irdma auxiliary driver, triggering device_delete and\nsubsequent client removal. During client removal, uverbs_client waits\nfor QP reference count to reach zero while cma_client holds the final\nreference, creating circular dependency and indefinite wait in iWARP\nmode. Skip QP reference count wait during device reset to prevent\ndeadlock.",
"id": "GHSA-hp4x-9rgh-5pgm",
"modified": "2026-10-15T03:35:41Z",
"published": "2026-04-24T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31565"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/009831768faeca3fb5950ce63f1b49594ec82389"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/464bbb844ba5b68e038220c34019069a0a9f1581"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f52370970ac07d352a7af4089e55e0e6425f827"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8a1c7621127a15a02494b96ee376406c064237b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/acb060bc2609c2eab49263968be59c7d59d497bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/adf0de36e52a48681eb58cbd7cbf6c8d200caa2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd8bcec2de5e24e05c34c9391940fda6f50e79b4"
}
],
"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-HP99-HC25-26X7
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-11 18:30A post-authentication flaw in the network two-phase commit protocol used for cross-shard transactions in MongoDB Server may lead to logical data inconsistencies under specific conditions which are not predictable and exist for a very short period of time. This error can cause the transaction coordination logic to misinterpret the transaction as committed, resulting in inconsistent state on those shards. This may lead to low integrity and availability impact.
This issue impacts MongoDB Server v8.0 versions prior to 8.0.16, MongoDB Server v7.0 versions prior to 7.0.26 and MongoDB server v8.2 versions prior to 8.2.2.
{
"affected": [],
"aliases": [
"CVE-2025-14345"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T16:17:41Z",
"severity": "LOW"
},
"details": "A post-authentication\u00a0flaw in the network two-phase commit protocol used for cross-shard transactions in MongoDB Server may lead to logical data inconsistencies under specific conditions which are not predictable and exist for a very short period of time. This error can cause the transaction coordination logic to misinterpret the transaction as committed, resulting in inconsistent state on those shards. This may lead to low integrity and availability impact.\n\nThis issue impacts MongoDB Server v8.0 versions prior to 8.0.16, MongoDB Server v7.0 versions prior to 7.0.26 and MongoDB server v8.2 versions prior to 8.2.2.",
"id": "GHSA-hp99-hc25-26x7",
"modified": "2025-12-11T18:30:41Z",
"published": "2025-12-09T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14345"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-106075"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/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-HPR5-WWH9-PJHF
Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-10-07 18:15A locking protection bypass flaw was found in some versions of gnome-shell as shipped within CentOS Stream 8, when the "Application menu" or "Window list" GNOME extensions are enabled. This flaw allows a physical attacker who has access to a locked system to kill existing applications and start new ones as the locked user, even if the session is still locked.
{
"affected": [],
"aliases": [
"CVE-2021-20315"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-18T18:15:00Z",
"severity": "MODERATE"
},
"details": "A locking protection bypass flaw was found in some versions of gnome-shell as shipped within CentOS Stream 8, when the \"Application menu\" or \"Window list\" GNOME extensions are enabled. This flaw allows a physical attacker who has access to a locked system to kill existing applications and start new ones as the locked user, even if the session is still locked.",
"id": "GHSA-hpr5-wwh9-pjhf",
"modified": "2022-10-07T18:15:55Z",
"published": "2022-02-19T00:01:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20315"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2006285"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HR22-G233-2GJG
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-05-14 15:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()
l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock.
Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del().
{
"affected": [],
"aliases": [
"CVE-2026-31499"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:48Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix deadlock in l2cap_conn_del()\n\nl2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer\nand id_addr_timer while holding conn-\u003elock. However, the work functions\nl2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire\nconn-\u003elock, creating a potential AB-BA deadlock if the work is already\nexecuting when l2cap_conn_del() takes the lock.\n\nMove the work cancellations before acquiring conn-\u003elock and use\ndisable_delayed_work_sync() to additionally prevent the works from\nbeing rearmed after cancellation, consistent with the pattern used in\nhci_conn_del().",
"id": "GHSA-hr22-g233-2gjg",
"modified": "2026-05-14T15:31:51Z",
"published": "2026-04-22T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31499"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00fdebbbc557a2fc21321ff2eaa22fd70c078608"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f26ecbd9cde621dd94be7ef252c7210b965a5c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d008460de352e534f6721de829b093368564ec66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7f35a4f7fd574f5889bb2e4b397e14cbb83f6da"
}
],
"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-HRH9-752P-34VJ
Vulnerability from github – Published: 2024-10-21 15:32 – Updated: 2024-10-22 18:32In the Linux kernel, the following vulnerability has been resolved:
KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock
Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores).
CPU0 CPU1 CPU2
1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu);
Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier():
cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier()
But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual.
The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list.
====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O
tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]
but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0
---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-47744"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T13:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock\n\nUse a dedicated mutex to guard kvm_usage_count to fix a potential deadlock\non x86 due to a chain of locks and SRCU synchronizations. Translating the\nbelow lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on\nCPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there\u0027s a writer, due to the\nfairness of r/w semaphores).\n\n CPU0 CPU1 CPU2\n1 lock(\u0026kvm-\u003eslots_lock);\n2 lock(\u0026vcpu-\u003emutex);\n3 lock(\u0026kvm-\u003esrcu);\n4 lock(cpu_hotplug_lock);\n5 lock(kvm_lock);\n6 lock(\u0026kvm-\u003eslots_lock);\n7 lock(cpu_hotplug_lock);\n8 sync(\u0026kvm-\u003esrcu);\n\nNote, there are likely more potential deadlocks in KVM x86, e.g. the same\npattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with\n__kvmclock_cpufreq_notifier():\n\n cpuhp_cpufreq_online()\n |\n -\u003e cpufreq_online()\n |\n -\u003e cpufreq_gov_performance_limits()\n |\n -\u003e __cpufreq_driver_target()\n |\n -\u003e __target_index()\n |\n -\u003e cpufreq_freq_transition_begin()\n |\n -\u003e cpufreq_notify_transition()\n |\n -\u003e ... __kvmclock_cpufreq_notifier()\n\nBut, actually triggering such deadlocks is beyond rare due to the\ncombination of dependencies and timings involved. E.g. the cpufreq\nnotifier is only used on older CPUs without a constant TSC, mucking with\nthe NX hugepage mitigation while VMs are running is very uncommon, and\ndoing so while also onlining/offlining a CPU (necessary to generate\ncontention on cpu_hotplug_lock) would be even more unusual.\n\nThe most robust solution to the general cpu_hotplug_lock issue is likely\nto switch vm_list to be an RCU-protected list, e.g. so that x86\u0027s cpufreq\nnotifier doesn\u0027t to take kvm_lock. For now, settle for fixing the most\nblatant deadlock, as switching to an RCU-protected list is a much more\ninvolved change, but add a comment in locking.rst to call out that care\nneeds to be taken when walking holding kvm_lock and walking vm_list.\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O\n ------------------------------------------------------\n tee/35048 is trying to acquire lock:\n ff6a80eced71e0a8 (\u0026kvm-\u003eslots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]\n\n but task is already holding lock:\n ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #3 (kvm_lock){+.+.}-{3:3}:\n __mutex_lock+0x6a/0xb40\n mutex_lock_nested+0x1f/0x30\n kvm_dev_ioctl+0x4fb/0xe50 [kvm]\n __se_sys_ioctl+0x7b/0xd0\n __x64_sys_ioctl+0x21/0x30\n x64_sys_call+0x15d0/0x2e60\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n -\u003e #2 (cpu_hotplug_lock){++++}-{0:0}:\n cpus_read_lock+0x2e/0xb0\n static_key_slow_inc+0x16/0x30\n kvm_lapic_set_base+0x6a/0x1c0 [kvm]\n kvm_set_apic_base+0x8f/0xe0 [kvm]\n kvm_set_msr_common+0x9ae/0xf80 [kvm]\n vmx_set_msr+0xa54/0xbe0 [kvm_intel]\n __kvm_set_msr+0xb6/0x1a0 [kvm]\n kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm]\n kvm_vcpu_ioctl+0x485/0x5b0 [kvm]\n __se_sys_ioctl+0x7b/0xd0\n __x64_sys_ioctl+0x21/0x30\n x64_sys_call+0x15d0/0x2e60\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n -\u003e #1 (\u0026kvm-\u003esrcu){.+.+}-{0:0}:\n __synchronize_srcu+0x44/0x1a0\n \n---truncated---",
"id": "GHSA-hrh9-752p-34vj",
"modified": "2024-10-22T18:32:09Z",
"published": "2024-10-21T15:32:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47744"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44d17459626052a2390457e550a12cb973506b2f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4777225ec89f52bb9ca16a33cfb44c189f1b7b47"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/760a196e6dcb29580e468b44b5400171dae184d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2764afce521fd9fd7a5ff6ed52ac2095873128a"
}
],
"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-HRWP-CV9C-VC93
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
net/smc: Do not re-initialize smc hashtables
INIT_HLIST_HEAD(&smc_v*_hashinfo.ht) are called after smc_nl_init(), proto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht being reset even though hash entries already exist and are being used, possibly resulting in a corrupted list.
Remove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in smc_init(); it is implicitly initialised to zero anyhow. Add HLIST_HEAD_INIT to the definitions for clarity.
{
"affected": [],
"aliases": [
"CVE-2026-64005"
],
"database_specific": {
"cwe_ids": [
"CWE-662",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:40Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Do not re-initialize smc hashtables\n\nINIT_HLIST_HEAD(\u0026smc_v*_hashinfo.ht) are called after smc_nl_init(),\nproto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht\nbeing reset even though hash entries already exist and are being used,\npossibly resulting in a corrupted list.\n\nRemove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in\nsmc_init(); it is implicitly initialised to zero anyhow. Add\nHLIST_HEAD_INIT to the definitions for clarity.",
"id": "GHSA-hrwp-cv9c-vc93",
"modified": "2026-07-20T15:31:55Z",
"published": "2026-07-19T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64005"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0cc9d0ac22d02f1ba1884de5d6de9eaf8b45d82d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2006605006e5a4a11d93e1ebdbbe95764d24276f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55cba6b883b41e5922c00ba9d4e3262131f46f1b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ec939367e700722ffbb1b7cacccbb1a3cf0ebd1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64c96e497d5ada0b90e99bf58f893aa2b73dcfbc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e4389b0038781f19f97895186ed941ff8ac1678"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cdc79c05cc375f68ae87b0c74fdaac1a5c93155a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed7a758313011885347b854e97cb95903ef3c3f7"
}
],
"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-HWG2-2RXQ-2XM4
Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2022-05-24 16:54An issue was discovered in OpenWrt libuci (aka Library for the Unified Configuration Interface) as used on Motorola CX2L MWR04L 1.01 and C1 MWR03 1.01 devices. /tmp/.uci/network locking is mishandled after reception of a long SetWanSettings command, leading to a device hang.
{
"affected": [],
"aliases": [
"CVE-2019-15513"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-23T07:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in OpenWrt libuci (aka Library for the Unified Configuration Interface) as used on Motorola CX2L MWR04L 1.01 and C1 MWR03 1.01 devices. /tmp/.uci/network locking is mishandled after reception of a long SetWanSettings command, leading to a device hang.",
"id": "GHSA-hwg2-2rxq-2xm4",
"modified": "2022-05-24T16:54:40Z",
"published": "2022-05-24T16:54:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15513"
},
{
"type": "WEB",
"url": "https://git.openwrt.org/?p=project/uci.git;a=commitdiff;h=19e29ffc15dbd958e8e6a648ee0982c68353516f"
},
{
"type": "WEB",
"url": "https://github.com/TeamSeri0us/pocs/blob/master/iot/morouter/motorola%E8%B7%AF%E7%94%B1%E5%99%A8%E6%96%87%E4%BB%B6%E8%A7%A3%E9%94%81%E6%BC%8F%E6%B4%9E.pdf"
},
{
"type": "WEB",
"url": "https://lists.infradead.org/pipermail/openwrt-devel/2019-November/019736.html"
},
{
"type": "WEB",
"url": "https://lists.openwrt.org/pipermail/openwrt-devel/2019-November/025453.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.