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.
724 vulnerabilities reference this CWE, most recent first.
GHSA-CWR2-26GQ-V2XR
Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-03-17 18:31In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.
{
"affected": [],
"aliases": [
"CVE-2024-26696"
],
"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\nnilfs2: fix hang in nilfs_lookup_dirty_data_buffers()\n\nSyzbot reported a hang issue in migrate_pages_batch() called by mbind()\nand nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.\n\nWhile migrate_pages_batch() locks a folio and waits for the writeback to\ncomplete, the log writer thread that should bring the writeback to\ncompletion picks up the folio being written back in\nnilfs_lookup_dirty_data_buffers() that it calls for subsequent log\ncreation and was trying to lock the folio. Thus causing a deadlock.\n\nIn the first place, it is unexpected that folios/pages in the middle of\nwriteback will be updated and become dirty. Nilfs2 adds a checksum to\nverify the validity of the log being written and uses it for recovery at\nmount, so data changes during writeback are suppressed. Since this is\nbroken, an unclean shutdown could potentially cause recovery to fail.\n\nInvestigation revealed that the root cause is that the wait for writeback\ncompletion in nilfs_page_mkwrite() is conditional, and if the backing\ndevice does not require stable writes, data may be modified without\nwaiting.\n\nFix these issues by making nilfs_page_mkwrite() wait for writeback to\nfinish regardless of the stable write requirement of the backing device.",
"id": "GHSA-cwr2-26gq-v2xr",
"modified": "2025-03-17T18:31:38Z",
"published": "2024-04-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26696"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CWWG-93GV-4R7H
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.
{
"affected": [],
"aliases": [
"CVE-2024-35806"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\n\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.",
"id": "GHSA-cwwg-93gv-4r7h",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35806"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CWX4-F9X9-PQHH
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-07-06 15:30In the Linux kernel, the following vulnerability has been resolved:
xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()
iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems.
For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock
For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock
Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms:
CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A
Fix by calling hrtimer_cancel() before acquiring the respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimer_cancel() already guarantees.
Found by source code audit.
{
"affected": [],
"aliases": [
"CVE-2026-53197"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state()\n\niptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock\nthat the timer callback also acquires, leading to an ABBA deadlock on\nSMP systems.\n\nFor the output timer (iptfs_timer):\n - iptfs_destroy_state() holds x-\u003elock, calls hrtimer_cancel()\n - iptfs_delay_timer() callback takes x-\u003elock\n\nFor the drop timer (drop_timer):\n - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel()\n - iptfs_drop_timer() callback takes drop_lock\n\nBoth timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq\ncontext. When hrtimer_cancel() is called for a soft timer that is\ncurrently executing on another CPU, hrtimer_cancel_wait_running() spins\non softirq_expiry_lock -- the same lock held by the softirq running the\ncallback. If the callback is blocked waiting for the spinlock held by\nthe caller of hrtimer_cancel(), a circular dependency forms:\n\n CPU 0: holds lock_A -\u003e waits for softirq_expiry_lock\n CPU 1: holds softirq_expiry_lock -\u003e waits for lock_A\n\nFix by calling hrtimer_cancel() before acquiring the respective locks.\nhrtimer_cancel() is safe to call without holding any lock and will wait\nfor any in-progress callback to complete. For the output timer, the\nlock is still acquired afterwards to drain the packet queue. For the\ndrop timer, the lock/unlock pair is removed entirely since it only\nexisted to serialize with the timer callback, which hrtimer_cancel()\nalready guarantees.\n\nFound by source code audit.",
"id": "GHSA-cwx4-f9x9-pqhh",
"modified": "2026-07-06T15:30:42Z",
"published": "2026-06-25T09:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53197"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/822b98d354e63e8249e85473c5f3c519f3c9cecc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a13ca53e47e500854a3b9ec18b5dc83acfec863e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c8a8a75b733467b00c08b91a38dbaf207a08ed6e"
}
],
"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-CX5C-HRVR-85GJ
Vulnerability from github – Published: 2024-05-01 15:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.
[hverkuil: fix minor spelling mistake in log message]
{
"affected": [],
"aliases": [
"CVE-2024-27072"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T13:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: usbtv: Remove useless locks in usbtv_video_free()\n\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\n\nBefore \u0027c838530d230b\u0027 this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\n\n\n[hverkuil: fix minor spelling mistake in log message]",
"id": "GHSA-cx5c-hrvr-85gj",
"modified": "2026-05-12T12:31:45Z",
"published": "2024-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27072"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e7d82ebb86e94643bdb30b0b5b077ed27dce1c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ec4641df57cbdfdc51bb4959afcdbcf5003ddb9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/65e6a2773d655172143cc0b927cdc89549842895"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bdd82c47b22a8befd617b723098b2a41b77373c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5ed208d04acf06781d63d30f9fa991e8d609ebd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dea46e246ef0f98d89d59a4229157cd9ffb636bf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CX67-J66H-CM23
Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-07-06 21:30In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Resolve soft lockup issue when opening /dev/sgX
The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup:
echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0
watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace:
sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size.
{
"affected": [],
"aliases": [
"CVE-2026-53304"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T20:17:23Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Resolve soft lockup issue when opening /dev/sgX\n\nThe parameter def_reserved_size defines the default buffer size reserved\nfor each Sg_fd and should be restricted to a range between 0 and 1,048,576\n(see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the\nfunction sg_proc_write_dressz enforces this limit, it is possible to bypass\nit by directly modifying the module parameter as shown below, which then\ncauses a soft lockup:\n\necho -1 \u003e /sys/module/sg/parameters/def_reserved_size\nexec 4\u003c\u003e /dev/sg0\n\nwatchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537]\nModules loaded:\nCPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134,\nPREEMPT disabled\nHardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version\n1.16.1-2.fc37 dated 04/01/2014\n...\nCall Trace:\n\n sg_build_reserve+0x5c/0xa0\n sg_add_sfp+0x168/0x270\n sg_open+0x16e/0x340\n chrdev_open+0xbe/0x230\n do_dentry_open+0x175/0x480\n vfs_open+0x34/0xf0\n do_open+0x265/0x3d0\n path_openat+0x110/0x290\n do_filp_open+0xc3/0x170\n do_sys_openat2+0x71/0xe0\n __x64_sys_openat+0x6d/0xa0\n do_syscall_64+0x62/0x310\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe fix is to use module_param_cb to validate and reject invalid values\nassigned to def_reserved_size.",
"id": "GHSA-cx67-j66h-cm23",
"modified": "2026-07-06T21:30:25Z",
"published": "2026-06-26T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53304"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1afd963fcd963db0dc5d47df6dfcf010c9c4647e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d74e0654ac908c65a8f20373091826fe43b1363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9676ca7b1ef31a3a65b3e61e7ce3b54ce7364202"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c47ccfb3d80dfed522ca06a5954ac97488d78c5a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5f4a211e82d04ccc1809311322c47023bbe66e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d06a310b45e153872033dd0cf19d5a2279121099"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe671d3c84ffb1b763d590c25195755adeaadaba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/feade299e932967de27519338d41de348fb5b061"
}
],
"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-CX7M-FCGF-9RJ4
Vulnerability from github – Published: 2024-09-18 09:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open
The mcp251x_hw_wake() function is called with the mpc_lock mutex held and disables the interrupt handler so that no interrupts can be processed while waking the device. If an interrupt has already occurred then waiting for the interrupt handler to complete will deadlock because it will be trying to acquire the same mutex.
CPU0 CPU1 ---- ---- mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlock
Use disable_irq_nosync() instead because the interrupt handler does everything while holding the mutex so it doesn't matter if it's still running.
{
"affected": [],
"aliases": [
"CVE-2024-46791"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T08:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\n\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\n\nCPU0 CPU1\n---- ----\nmcp251x_open()\n mutex_lock(\u0026priv-\u003emcp_lock)\n request_threaded_irq()\n \u003cinterrupt\u003e\n mcp251x_can_ist()\n mutex_lock(\u0026priv-\u003emcp_lock)\n mcp251x_hw_wake()\n disable_irq() \u003c-- deadlock\n\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0027t matter if it\u0027s still\nrunning.",
"id": "GHSA-cx7m-fcgf-9rj4",
"modified": "2025-11-04T00:31:29Z",
"published": "2024-09-18T09:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a49b6b1caf5cefc05264d29079d52c99cb188e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/513c8fc189b52f7922e36bdca58997482b198f0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7dd9c26bd6cf679bcfdef01a8659791aa6487a29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fecde9c3f9a4b97b68bb97c9f47e5b662586ba7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e554113a1cd2a9cfc6c7af7bdea2141c5757e188"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f7ab9e14b23a3eac6714bdc4dba244d8aa1ef646"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CXF4-996M-V4M3
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
__kernel_map_pages() is a debug function which clears the valid bit in page table entry for deallocated pages to detect illegal memory accesses to freed pages.
This function set/clear the valid bit using __set_memory(). __set_memory() acquires init_mm's semaphore, and this operation may sleep. This is problematic, because __kernel_map_pages() can be called in atomic context, and thus is illegal to sleep. An example warning that this causes:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd preempt_count: 2, expected: 0 CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37 Hardware name: riscv-virtio,qemu (DT) Call Trace: [] dump_backtrace+0x1c/0x24 [] show_stack+0x2c/0x38 [] dump_stack_lvl+0x5a/0x72 [] dump_stack+0x14/0x1c [] __might_resched+0x104/0x10e [] __might_sleep+0x3e/0x62 [] down_write+0x20/0x72 [] __set_memory+0x82/0x2fa [] __kernel_map_pages+0x5a/0xd4 [] __alloc_pages_bulk+0x3b2/0x43a [] __vmalloc_node_range+0x196/0x6ba [] copy_process+0x72c/0x17ec [] kernel_clone+0x60/0x2fe [] kernel_thread+0x82/0xa0 [] kthreadd+0x14a/0x1be [] ret_from_fork+0xe/0x1c
Rewrite this function with apply_to_existing_page_range(). It is fine to not have any locking, because __kernel_map_pages() works with pages being allocated/deallocated and those pages are not changed by anyone else in the meantime.
{
"affected": [],
"aliases": [
"CVE-2024-40915"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: rewrite __kernel_map_pages() to fix sleeping in invalid context\n\n__kernel_map_pages() is a debug function which clears the valid bit in page\ntable entry for deallocated pages to detect illegal memory accesses to\nfreed pages.\n\nThis function set/clear the valid bit using __set_memory(). __set_memory()\nacquires init_mm\u0027s semaphore, and this operation may sleep. This is\nproblematic, because __kernel_map_pages() can be called in atomic context,\nand thus is illegal to sleep. An example warning that this causes:\n\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd\npreempt_count: 2, expected: 0\nCPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n[\u003cffffffff800060dc\u003e] dump_backtrace+0x1c/0x24\n[\u003cffffffff8091ef6e\u003e] show_stack+0x2c/0x38\n[\u003cffffffff8092baf8\u003e] dump_stack_lvl+0x5a/0x72\n[\u003cffffffff8092bb24\u003e] dump_stack+0x14/0x1c\n[\u003cffffffff8003b7ac\u003e] __might_resched+0x104/0x10e\n[\u003cffffffff8003b7f4\u003e] __might_sleep+0x3e/0x62\n[\u003cffffffff8093276a\u003e] down_write+0x20/0x72\n[\u003cffffffff8000cf00\u003e] __set_memory+0x82/0x2fa\n[\u003cffffffff8000d324\u003e] __kernel_map_pages+0x5a/0xd4\n[\u003cffffffff80196cca\u003e] __alloc_pages_bulk+0x3b2/0x43a\n[\u003cffffffff8018ee82\u003e] __vmalloc_node_range+0x196/0x6ba\n[\u003cffffffff80011904\u003e] copy_process+0x72c/0x17ec\n[\u003cffffffff80012ab4\u003e] kernel_clone+0x60/0x2fe\n[\u003cffffffff80012f62\u003e] kernel_thread+0x82/0xa0\n[\u003cffffffff8003552c\u003e] kthreadd+0x14a/0x1be\n[\u003cffffffff809357de\u003e] ret_from_fork+0xe/0x1c\n\nRewrite this function with apply_to_existing_page_range(). It is fine to\nnot have any locking, because __kernel_map_pages() works with pages being\nallocated/deallocated and those pages are not changed by anyone else in the\nmeantime.",
"id": "GHSA-cxf4-996m-v4m3",
"modified": "2025-11-04T00:30:53Z",
"published": "2024-07-12T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40915"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8661a7af04991201640863ad1a0983173f84b5eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/919f8626099d9909b9a9620b05e8c8ab06581876"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5257ceb19d92069195254866421f425aea42915"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fb1cf0878328fe75d47f0aed0a65b30126fcefc4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F225-F9RP-HG69
Vulnerability from github – Published: 2024-12-28 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
bpf: fix recursive lock when verdict program return SK_PASS
When the stream_verdict program returns SK_PASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9.
''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock
'''
This topic has been discussed before, but it has not been fixed. Previous discussion: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
{
"affected": [],
"aliases": [
"CVE-2024-56694"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-28T10:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix recursive lock when verdict program return SK_PASS\n\nWhen the stream_verdict program returns SK_PASS, it places the received skb\ninto its own receive queue, but a recursive lock eventually occurs, leading\nto an operating system deadlock. This issue has been present since v6.9.\n\n\u0027\u0027\u0027\nsk_psock_strp_data_ready\n write_lock_bh(\u0026sk-\u003esk_callback_lock)\n strp_data_ready\n strp_read_sock\n read_sock -\u003e tcp_read_sock\n strp_recv\n cb.rcv_msg -\u003e sk_psock_strp_read\n # now stream_verdict return SK_PASS without peer sock assign\n __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)\n sk_psock_verdict_apply\n sk_psock_skb_ingress_self\n sk_psock_skb_ingress_enqueue\n sk_psock_data_ready\n read_lock_bh(\u0026sk-\u003esk_callback_lock) \u003c= dead lock\n\n\u0027\u0027\u0027\n\nThis topic has been discussed before, but it has not been fixed.\nPrevious discussion:\nhttps://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch",
"id": "GHSA-f225-f9rp-hg69",
"modified": "2025-11-03T21:32:01Z",
"published": "2024-12-28T12:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56694"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/01f1b88acfd79103da0610b45471f6c88ea98d72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/078f7e1521442a55db4bed812a2fbaf02ac33819"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/221109ba2127eabd0aa64718543638b58b15df56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d407fe578"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6694f7acd625ed854bf6342926e771d65dad7f69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ca2a1eeadf09862190b2810697702d803ceef2d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da2bc8a0c8f3ac66fdf980fc59936f851a083561"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f84c5ef6ca23cc2f72f3b830d74f67944684bb05"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F266-QPMF-VXQX
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2022-05-24 17:31This issue was addressed with improved checks. This issue is fixed in iOS 14.0 and iPadOS 14.0, watchOS 7.0. The screen lock may not engage after the specified time period.
{
"affected": [],
"aliases": [
"CVE-2020-9946"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-16T17:15:00Z",
"severity": "MODERATE"
},
"details": "This issue was addressed with improved checks. This issue is fixed in iOS 14.0 and iPadOS 14.0, watchOS 7.0. The screen lock may not engage after the specified time period.",
"id": "GHSA-f266-qpmf-vxqx",
"modified": "2022-05-24T17:31:09Z",
"published": "2022-05-24T17:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9946"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT211844"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT211850"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Nov/20"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Nov/22"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F2F9-54CV-V7GF
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-04 15:35In the Linux kernel, the following vulnerability has been resolved:
mm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup
We hit a real softlockup in an internal stress test environment. The workload was LTP memory/swap stress on a large arm64 machine, with 320 CPUs, about 1TB memory and an 8.6GB swap device. The system was under heavy load and the swap device had a large number of full clusters. The softlockup was triggered during a stress test after about 3 days.
So, add periodic cond_resched() calls during large full_clusters reclaim operations to prevent softlockup issues.
Detailed call trace as follow:
PID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: "kworker/48:7" #0 [ffff800080183d10] __crash_kexec at ffffa4c1361e5de4 #1 [ffff800080183d90] panic at ffffa4c1360d5e9c #2 [ffff800080183e20] watchdog_timer_fn at ffffa4c136231fa8 ... #16 [ffff8000c4ad3cb0] swap_cache_del_folio at ffffa4c1363e1614 #17 [ffff8000c4ad3ce0] __try_to_reclaim_swap at ffffa4c1363e4bfc #18 [ffff8000c4ad3d40] swap_reclaim_full_clusters at ffffa4c1363e5474 #19 [ffff8000c4ad3da0] swap_reclaim_work at ffffa4c1363e550c #20 [ffff8000c4ad3dc0] process_one_work at ffffa4c136102edc #21 [ffff8000c4ad3e10] worker_thread at ffffa4c136103398 #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c
{
"affected": [],
"aliases": [
"CVE-2026-64415"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup\n\nWe hit a real softlockup in an internal stress test environment. The\nworkload was LTP memory/swap stress on a large arm64 machine, with 320\nCPUs, about 1TB memory and an 8.6GB swap device. The system was under\nheavy load and the swap device had a large number of full clusters. The\nsoftlockup was triggered during a stress test after about 3 days.\n\nSo, add periodic cond_resched() calls during large full_clusters\nreclaim operations to prevent softlockup issues.\n\nDetailed call trace as follow:\n\nPID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: \"kworker/48:7\"\n #0 [ffff800080183d10] __crash_kexec at ffffa4c1361e5de4\n #1 [ffff800080183d90] panic at ffffa4c1360d5e9c\n #2 [ffff800080183e20] watchdog_timer_fn at ffffa4c136231fa8\n ...\n #16 [ffff8000c4ad3cb0] swap_cache_del_folio at ffffa4c1363e1614\n #17 [ffff8000c4ad3ce0] __try_to_reclaim_swap at ffffa4c1363e4bfc\n #18 [ffff8000c4ad3d40] swap_reclaim_full_clusters at ffffa4c1363e5474\n #19 [ffff8000c4ad3da0] swap_reclaim_work at ffffa4c1363e550c\n #20 [ffff8000c4ad3dc0] process_one_work at ffffa4c136102edc\n #21 [ffff8000c4ad3e10] worker_thread at ffffa4c136103398\n #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c",
"id": "GHSA-f2f9-54cv-v7gf",
"modified": "2026-09-04T15:35:54Z",
"published": "2026-07-25T12:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64415"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a55fdf9f746a1a6ced7fd62ea1080b8a917e0b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60cbe67d1342f34b66df1c2ee328e3cd333767d7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66366d291f666ddeda5f8c84f253e308de3e6b55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69c0e6246575b780ae0d3f411c749bcf13c221f3"
}
],
"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.