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-CRW3-PH9V-P9P3
Vulnerability from github – Published: 2025-10-07 18:31 – Updated: 2026-02-04 18:30In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix locking in pdc_iodc_print() firmware call
Utilize pdc_lock spinlock to protect parallel modifications of the iodc_dbuf[] buffer, check length to prevent buffer overflow of iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong indentings.
{
"affected": [],
"aliases": [
"CVE-2022-50518"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T16:15:35Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix locking in pdc_iodc_print() firmware call\n\nUtilize pdc_lock spinlock to protect parallel modifications of the\niodc_dbuf[] buffer, check length to prevent buffer overflow of\niodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong\nindentings.",
"id": "GHSA-crw3-ph9v-p9p3",
"modified": "2026-02-04T18:30:19Z",
"published": "2025-10-07T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50518"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/04a603058e70b8b881bb7860b8bd649f931f2591"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/553bc5890ed96a8d006224c3a4673c47fee0d12a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7236aae5f81f3efbd93d0601e74fc05994bc2580"
}
],
"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-CRW5-QP92-P6M7
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2024-09-09 18:30In the Linux kernel, the following vulnerability has been resolved:
f2fs: don't set RO when shutting down f2fs
Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below.
f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread);
{
"affected": [],
"aliases": [
"CVE-2024-40969"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: don\u0027t set RO when shutting down f2fs\n\nShutdown does not check the error of thaw_super due to readonly, which\ncauses a deadlock like below.\n\nf2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread\n - bdev_freeze\n - freeze_super\n - f2fs_stop_checkpoint()\n - f2fs_handle_critical_error - sb_start_write\n - set RO - waiting\n - bdev_thaw\n - thaw_super_locked\n - return -EINVAL, if sb_rdonly()\n - f2fs_stop_discard_thread\n -\u003e wait for kthread_stop(discard_thread);",
"id": "GHSA-crw5-qp92-p6m7",
"modified": "2024-09-09T18:30:29Z",
"published": "2024-07-12T15:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40969"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563"
}
],
"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-CW78-Q654-793W
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-10-31 21:30In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Avoid use of GFP_KERNEL in atomic context
Using GFP_KERNEL in preemption disable context, causing below warning when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
[ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 [ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 [ 32.558707] preempt_count: 1, expected: 0 [ 32.562710] RCU nest depth: 0, expected: 0 [ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7 [ 32.576188] Hardware name: Marvell CN106XX board (DT) [ 32.581232] Call trace: [ 32.583670] dump_backtrace.part.0+0xe0/0xf0 [ 32.587937] show_stack+0x18/0x30 [ 32.591245] dump_stack_lvl+0x68/0x84 [ 32.594900] dump_stack+0x18/0x34 [ 32.598206] __might_resched+0x12c/0x160 [ 32.602122] __might_sleep+0x48/0xa0 [ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0 [ 32.610301] __kmalloc+0x58/0x190 [ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314 [ 32.618134] otx2_open+0x1d4/0x9d0
To avoid use of GFP_ATOMIC for memory allocation, disable preemption after all memory allocation is done.
{
"affected": [],
"aliases": [
"CVE-2023-53030"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Avoid use of GFP_KERNEL in atomic context\n\nUsing GFP_KERNEL in preemption disable context, causing below warning\nwhen CONFIG_DEBUG_ATOMIC_SLEEP is enabled.\n\n[ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274\n[ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n[ 32.558707] preempt_count: 1, expected: 0\n[ 32.562710] RCU nest depth: 0, expected: 0\n[ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7\n[ 32.576188] Hardware name: Marvell CN106XX board (DT)\n[ 32.581232] Call trace:\n[ 32.583670] dump_backtrace.part.0+0xe0/0xf0\n[ 32.587937] show_stack+0x18/0x30\n[ 32.591245] dump_stack_lvl+0x68/0x84\n[ 32.594900] dump_stack+0x18/0x34\n[ 32.598206] __might_resched+0x12c/0x160\n[ 32.602122] __might_sleep+0x48/0xa0\n[ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0\n[ 32.610301] __kmalloc+0x58/0x190\n[ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314\n[ 32.618134] otx2_open+0x1d4/0x9d0\n\nTo avoid use of GFP_ATOMIC for memory allocation, disable preemption\nafter all memory allocation is done.",
"id": "GHSA-cw78-q654-793w",
"modified": "2025-10-31T21:30:52Z",
"published": "2025-03-27T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53030"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1eb57b87f106c90cee6b2a56a10f2e29c7a25f3e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2827c4eb429db64befdca11362e2b1c5f524f6ba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87b93b678e95c7d93fe6a55b0e0fbda26d8c7760"
}
],
"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-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"
}
]
}
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.