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.
729 vulnerabilities reference this CWE, most recent first.
GHSA-V4FX-VWM3-3682
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-27 15:30In the Linux kernel, the following vulnerability has been resolved:
erofs: add GFP_NOIO in the bio completion if needed
The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL.
Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios.
Trimmed down the call stack, as follows:
f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!!
Use memalloc_noio_{save,restore}() to wrap up this path.
{
"affected": [],
"aliases": [
"CVE-2026-31467"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:42Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: add GFP_NOIO in the bio completion if needed\n\nThe bio completion path in the process context (e.g. dm-verity)\nwill directly call into decompression rather than trigger another\nworkqueue context for minimal scheduling latencies, which can\nthen call vm_map_ram() with GFP_KERNEL.\n\nDue to insufficient memory, vm_map_ram() may generate memory\nswapping I/O, which can cause submit_bio_wait to deadlock\nin some scenarios.\n\nTrimmed down the call stack, as follows:\n\nf2fs_submit_read_io\n submit_bio //bio_list is initialized.\n mmc_blk_mq_recovery\n z_erofs_endio\n vm_map_ram\n __pte_alloc_kernel\n __alloc_pages_direct_reclaim\n shrink_folio_list\n __swap_writepage\n submit_bio_wait //bio_list is non-NULL, hang!!!\n\nUse memalloc_noio_{save,restore}() to wrap up this path.",
"id": "GHSA-v4fx-vwm3-3682",
"modified": "2026-04-27T15:30:38Z",
"published": "2026-04-22T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31467"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/378949f46e897204384f3f5f91e42e93e3f87568"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c8ecdcfbfb0b0c6a82a4ebadc1ddea61609b902"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c23df30915f83e7257c8625b690a1cece94142a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d6565ea662e17d45a577184b0011bd69de22dc2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9d8360cb66e3b599d89d2526e7da8b530ebf2ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da40464064599eefe78749f75cd2bba371044c04"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e83e20b82859f0588e9a52a6fa9fea704a2061cf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V5MH-2J9W-GWPX
Vulnerability from github – Published: 2023-02-06 21:30 – Updated: 2023-02-14 18:30In vcu, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519159; Issue ID: ALPS07519159.
{
"affected": [],
"aliases": [
"CVE-2023-20619"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-06T20:15:00Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible memory corruption due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519159; Issue ID: ALPS07519159.",
"id": "GHSA-v5mh-2j9w-gwpx",
"modified": "2023-02-14T18:30:20Z",
"published": "2023-02-06T21:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20619"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/February-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V5PW-W6W2-2R5Q
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2024-11-01 15:31In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc_submit: add missing locking in wedged_fini
Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock.
(cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)
{
"affected": [],
"aliases": [
"CVE-2024-49943"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/guc_submit: add missing locking in wedged_fini\n\nAny non-wedged queue can have a zero refcount here and can be running\nconcurrently with an async queue destroy, therefore dereferencing the\nqueue ptr to check wedge status after the lookup can trigger UAF if\nqueue is not wedged. Fix this by keeping the submission_state lock held\naround the check to postpone the free and make the check safe, before\ndropping again around the put() to avoid the deadlock.\n\n(cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)",
"id": "GHSA-v5pw-w6w2-2r5q",
"modified": "2024-11-01T15:31:45Z",
"published": "2024-10-21T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49943"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/790533e44bfc7af929842fccd9674c9f424d4627"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d88f9bab7e62dd0dbe983fa70cf040042a60cc84"
}
],
"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-V62Q-CM8M-9JHX
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-17 15:30In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix PM related deadlocks in MS IOCTLs
Prevent runtime resume/suspend while MS IOCTLs are in progress. Failed suspend will call ivpu_ms_cleanup() that would try to acquire file_priv->ms_lock, which is already held by the IOCTLs.
{
"affected": [],
"aliases": [
"CVE-2025-37848"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix PM related deadlocks in MS IOCTLs\n\nPrevent runtime resume/suspend while MS IOCTLs are in progress.\nFailed suspend will call ivpu_ms_cleanup() that would try to acquire\nfile_priv-\u003ems_lock, which is already held by the IOCTLs.",
"id": "GHSA-v62q-cm8m-9jhx",
"modified": "2025-11-17T15:30:31Z",
"published": "2025-05-09T09:33:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37848"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84547128526441b45c3c241419dececf20c30104"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/afada73000bef7c79a22f0d7e93fac414eeff19e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3d9fc2f2746b52e9f820a13c53b4418bec04b48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d893da85e06edf54737bb80648bb58ba8fd56d9f"
}
],
"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-V62X-6V8M-46VV
Vulnerability from github – Published: 2025-01-19 12:31 – Updated: 2025-02-03 15:32In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: remove kernfs active break
A warning was found:
WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828 CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0 RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202 RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000 RDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04 RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180 R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08 R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0 FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kernfs_drain+0x15e/0x2f0 __kernfs_remove+0x165/0x300 kernfs_remove_by_name_ns+0x7b/0xc0 cgroup_rm_file+0x154/0x1c0 cgroup_addrm_files+0x1c2/0x1f0 css_clear_dir+0x77/0x110 kill_css+0x4c/0x1b0 cgroup_destroy_locked+0x194/0x380 cgroup_rmdir+0x2a/0x140
It can be explained by: rmdir echo 1 > cpuset.cpus kernfs_fop_write_iter // active=0 cgroup_rm_file kernfs_remove_by_name_ns kernfs_get_active // active=1 __kernfs_remove // active=0x80000002 kernfs_drain cpuset_write_resmask wait_event //waiting (active == 0x80000001) kernfs_break_active_protection // active = 0x80000001 // continue kernfs_unbreak_active_protection // active = 0x80000002 ... kernfs_should_drain_open_files // warning occurs kernfs_put_active
This warning is caused by 'kernfs_break_active_protection' when it is writing to cpuset.cpus, and the cgroup is removed concurrently.
The commit 3a5a6d0c2b03 ("cpuset: don't nest cgroup_mutex inside get_online_cpus()") made cpuset_hotplug_workfn asynchronous, This change involves calling flush_work(), which can create a multiple processes circular locking dependency that involve cgroup_mutex, potentially leading to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break kernfs active protection in cpuset_write_resmask()") added 'kernfs_break_active_protection' in the cpuset_write_resmask. This could lead to this warning.
After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpuset_write_resmask no longer needs to wait the hotplug to finish, which means that concurrent hotplug and cpuset operations are no longer possible. Therefore, the deadlock doesn't exist anymore and it does not have to 'break active protection' now. To fix this warning, just remove kernfs_break_active_protection operation in the 'cpuset_write_resmask'.
{
"affected": [],
"aliases": [
"CVE-2025-21634"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-19T11:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: remove kernfs active break\n\nA warning was found:\n\nWARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828\nCPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G\nRIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0\nRSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202\nRAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000\nRDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04\nRBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180\nR10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08\nR13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0\nFS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n kernfs_drain+0x15e/0x2f0\n __kernfs_remove+0x165/0x300\n kernfs_remove_by_name_ns+0x7b/0xc0\n cgroup_rm_file+0x154/0x1c0\n cgroup_addrm_files+0x1c2/0x1f0\n css_clear_dir+0x77/0x110\n kill_css+0x4c/0x1b0\n cgroup_destroy_locked+0x194/0x380\n cgroup_rmdir+0x2a/0x140\n\nIt can be explained by:\nrmdir \t\t\t\techo 1 \u003e cpuset.cpus\n\t\t\t\tkernfs_fop_write_iter // active=0\ncgroup_rm_file\nkernfs_remove_by_name_ns\tkernfs_get_active // active=1\n__kernfs_remove\t\t\t\t\t // active=0x80000002\nkernfs_drain\t\t\tcpuset_write_resmask\nwait_event\n//waiting (active == 0x80000001)\n\t\t\t\tkernfs_break_active_protection\n\t\t\t\t// active = 0x80000001\n// continue\n\t\t\t\tkernfs_unbreak_active_protection\n\t\t\t\t// active = 0x80000002\n...\nkernfs_should_drain_open_files\n// warning occurs\n\t\t\t\tkernfs_put_active\n\nThis warning is caused by \u0027kernfs_break_active_protection\u0027 when it is\nwriting to cpuset.cpus, and the cgroup is removed concurrently.\n\nThe commit 3a5a6d0c2b03 (\"cpuset: don\u0027t nest cgroup_mutex inside\nget_online_cpus()\") made cpuset_hotplug_workfn asynchronous, This change\ninvolves calling flush_work(), which can create a multiple processes\ncircular locking dependency that involve cgroup_mutex, potentially leading\nto a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 (\"cpuset: break\nkernfs active protection in cpuset_write_resmask()\") added\n\u0027kernfs_break_active_protection\u0027 in the cpuset_write_resmask. This could\nlead to this warning.\n\nAfter the commit 2125c0034c5d (\"cgroup/cpuset: Make cpuset hotplug\nprocessing synchronous\"), the cpuset_write_resmask no longer needs to\nwait the hotplug to finish, which means that concurrent hotplug and cpuset\noperations are no longer possible. Therefore, the deadlock doesn\u0027t exist\nanymore and it does not have to \u0027break active protection\u0027 now. To fix this\nwarning, just remove kernfs_break_active_protection operation in the\n\u0027cpuset_write_resmask\u0027.",
"id": "GHSA-v62x-6v8m-46vv",
"modified": "2025-02-03T15:32:01Z",
"published": "2025-01-19T12:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21634"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11cb1d643a74665a4e14749414f48f82cbc15c64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cb97a927fffe443e1e7e8eddbfebfdb062e86ed"
}
],
"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-V647-R38J-39FQ
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-03 18:31In the Linux kernel, the following vulnerability has been resolved:
USB: serial: digi_acceleport: fix hard lockup on disconnect
If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled.
Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect.
This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.
{
"affected": [],
"aliases": [
"CVE-2026-64334"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: digi_acceleport: fix hard lockup on disconnect\n\nIf submitting the OOB write urb fails persistently (e.g if the device is\nbeing disconnected) the driver would loop indefinitely with interrupts\ndisabled.\n\nCheck for urb submission errors when sending OOB commands to avoid\nhanging if, for example, open(), set_termios() or close() races with a\nphysical disconnect.\n\nThis is issue was flagged by Sashiko when reviewing an unrelated change\nto the driver.",
"id": "GHSA-v647-r38j-39fq",
"modified": "2026-09-03T18:31:16Z",
"published": "2026-07-25T12:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2067b3838da6e4af03bae3630414193188d754b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b7dc482f859f2d027db07ff0efc1c5df5b3451a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a82d842e8c35227d7227f19e5e654df1451782c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c1ea24b53bf3bfb859f0a05573997487975da23"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a8592ace932081ea11aea41c460a1ca0f6344a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e51147c2744d15730084dc89cc99180d3de4184"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79bc131df0e50f8f663c1fdbbe952aaf193a8d39"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bcfeae431db9986c2b313e6a760f2ac8df61e138"
}
],
"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-V82J-FHF7-MWX2
Vulnerability from github – Published: 2024-08-17 09:30 – Updated: 2024-08-19 21:35In the Linux kernel, the following vulnerability has been resolved:
block: fix deadlock between sd_remove & sd_release
Our test report the following hung task:
[ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc
[ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac
T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex)
SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in this scenario. This is a classic ABBA deadlock. To fix the deadlock, make sure we don't try to acquire disk->open_mutex after freezing the queue.
{
"affected": [],
"aliases": [
"CVE-2024-42294"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-17T09:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix deadlock between sd_remove \u0026 sd_release\n\nOur test report the following hung task:\n\n[ 2538.459400] INFO: task \"kworker/0:0\":7 blocked for more than 188 seconds.\n[ 2538.459427] Call trace:\n[ 2538.459430] __switch_to+0x174/0x338\n[ 2538.459436] __schedule+0x628/0x9c4\n[ 2538.459442] schedule+0x7c/0xe8\n[ 2538.459447] schedule_preempt_disabled+0x24/0x40\n[ 2538.459453] __mutex_lock+0x3ec/0xf04\n[ 2538.459456] __mutex_lock_slowpath+0x14/0x24\n[ 2538.459459] mutex_lock+0x30/0xd8\n[ 2538.459462] del_gendisk+0xdc/0x350\n[ 2538.459466] sd_remove+0x30/0x60\n[ 2538.459470] device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459474] device_release_driver+0x18/0x28\n[ 2538.459478] bus_remove_device+0x15c/0x174\n[ 2538.459483] device_del+0x1d0/0x358\n[ 2538.459488] __scsi_remove_device+0xa8/0x198\n[ 2538.459493] scsi_forget_host+0x50/0x70\n[ 2538.459497] scsi_remove_host+0x80/0x180\n[ 2538.459502] usb_stor_disconnect+0x68/0xf4\n[ 2538.459506] usb_unbind_interface+0xd4/0x280\n[ 2538.459510] device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459514] device_release_driver+0x18/0x28\n[ 2538.459518] bus_remove_device+0x15c/0x174\n[ 2538.459523] device_del+0x1d0/0x358\n[ 2538.459528] usb_disable_device+0x84/0x194\n[ 2538.459532] usb_disconnect+0xec/0x300\n[ 2538.459537] hub_event+0xb80/0x1870\n[ 2538.459541] process_scheduled_works+0x248/0x4dc\n[ 2538.459545] worker_thread+0x244/0x334\n[ 2538.459549] kthread+0x114/0x1bc\n\n[ 2538.461001] INFO: task \"fsck.\":15415 blocked for more than 188 seconds.\n[ 2538.461014] Call trace:\n[ 2538.461016] __switch_to+0x174/0x338\n[ 2538.461021] __schedule+0x628/0x9c4\n[ 2538.461025] schedule+0x7c/0xe8\n[ 2538.461030] blk_queue_enter+0xc4/0x160\n[ 2538.461034] blk_mq_alloc_request+0x120/0x1d4\n[ 2538.461037] scsi_execute_cmd+0x7c/0x23c\n[ 2538.461040] ioctl_internal_command+0x5c/0x164\n[ 2538.461046] scsi_set_medium_removal+0x5c/0xb0\n[ 2538.461051] sd_release+0x50/0x94\n[ 2538.461054] blkdev_put+0x190/0x28c\n[ 2538.461058] blkdev_release+0x28/0x40\n[ 2538.461063] __fput+0xf8/0x2a8\n[ 2538.461066] __fput_sync+0x28/0x5c\n[ 2538.461070] __arm64_sys_close+0x84/0xe8\n[ 2538.461073] invoke_syscall+0x58/0x114\n[ 2538.461078] el0_svc_common+0xac/0xe0\n[ 2538.461082] do_el0_svc+0x1c/0x28\n[ 2538.461087] el0_svc+0x38/0x68\n[ 2538.461090] el0t_64_sync_handler+0x68/0xbc\n[ 2538.461093] el0t_64_sync+0x1a8/0x1ac\n\n T1:\t\t\t\tT2:\n sd_remove\n del_gendisk\n __blk_mark_disk_dead\n blk_freeze_queue_start\n ++q-\u003emq_freeze_depth\n \t\t\t\tbdev_release\n \t\t\t\tmutex_lock(\u0026disk-\u003eopen_mutex)\n \t\t\t\tsd_release\n \t\t\t\tscsi_execute_cmd\n \t\t\t\tblk_queue_enter\n \t\t\t\twait_event(!q-\u003emq_freeze_depth)\n mutex_lock(\u0026disk-\u003eopen_mutex)\n\nSCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in\nthis scenario. This is a classic ABBA deadlock. To fix the deadlock,\nmake sure we don\u0027t try to acquire disk-\u003eopen_mutex after freezing\nthe queue.",
"id": "GHSA-v82j-fhf7-mwx2",
"modified": "2024-08-19T21:35:09Z",
"published": "2024-08-17T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a5625a83eac91fdff1d5f0202ecfc45a31983c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e04da2dc7013af50ed3a2beb698d5168d1e594b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5418f48a93b69ed9e6a2281eee06b412f14a544"
}
],
"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-V8PP-R8HM-GFQW
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2024-10-29 21:30In the Linux kernel, the following vulnerability has been resolved:
smb3: missing lock when picking channel
Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index.
Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")
{
"affected": [],
"aliases": [
"CVE-2024-35999"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: missing lock when picking channel\n\nCoverity spotted a place where we should have been holding the\nchannel lock when accessing the ses channel index.\n\nAddresses-Coverity: 1582039 (\"Data race condition (MISSING_LOCK)\")",
"id": "GHSA-v8pp-r8hm-gfqw",
"modified": "2024-10-29T21:30:47Z",
"published": "2024-05-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35999"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729"
}
],
"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-V8QX-G69V-PPH9
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-14 21:31In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: fix deadlock in hid_post_reset()
You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.
{
"affected": [],
"aliases": [
"CVE-2026-53037"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: usbhid: fix deadlock in hid_post_reset()\n\nYou can build a USB device that includes a HID component\nand a storage or UAS component. The components can be reset\nonly together. That means that hid_pre_reset() and hid_post_reset()\nare in the block IO error handling. Hence no memory allocation\nused in them may do block IO because the IO can deadlock\non the mutex held while resetting a device and calling the\ninterface drivers.\nUse GFP_NOIO for all allocations in them.",
"id": "GHSA-v8qx-g69v-pph9",
"modified": "2026-07-14T21:31:29Z",
"published": "2026-06-24T18:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53037"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e900465296ce9fb12ed47dc77389b8dde95bfe0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56d318ef8766f0deb08517fd8f3007256ea7997d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90550af0aad5e75110073c501e4fb42fca20ff80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad4505d2ab3aaac6498f17649608e70e80034bf2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3d16611d7cd78e9d5c6baa19b61b7caf9f1ab5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7abd0e6c87441e99c759d40eb6fe589634e3041"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eeceb6f4dd42065fdda3a526a93d08b8fb90fb69"
}
],
"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-V97Q-699F-9M4X
Vulnerability from github – Published: 2026-02-02 09:30 – Updated: 2026-02-03 00:30In imgsys, there is a possible memory corruption due to improper locking. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10363254; Issue ID: MSV-5617.
{
"affected": [],
"aliases": [
"CVE-2026-20415"
],
"database_specific": {
"cwe_ids": [
"CWE-415",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-02T09:15:56Z",
"severity": "MODERATE"
},
"details": "In imgsys, there is a possible memory corruption due to improper locking. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10363254; Issue ID: MSV-5617.",
"id": "GHSA-v97q-699f-9m4x",
"modified": "2026-02-03T00:30:18Z",
"published": "2026-02-02T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20415"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/February-2026"
}
],
"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.