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.
721 vulnerabilities reference this CWE, most recent first.
GHSA-9CC8-5CMC-HCJ3
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30
{
"affected": [],
"aliases": [
"CVE-2022-49322"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix sleeping function called from invalid context on RT kernel\n\nWhen setting bootparams=\"trace_event=initcall:initcall_start tp_printk=1\" in the\ncmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the\natomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,\nthese locks are replaced with sleepable rt-spinlock, so the stack calltrace will\nbe triggered.\nFix it by raw_spin_lock_irqsave when PREEMPT_RT and \"trace_event=initcall:initcall_start\ntp_printk=1\" enabled.\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n preempt_count: 2, expected: 0\n RCU nest depth: 0, expected: 0\n Preemption disabled at:\n [\u003cffffffff8992303e\u003e] try_to_wake_up+0x7e/0xba0\n CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x60/0x8c\n dump_stack+0x10/0x12\n __might_resched.cold+0x11d/0x155\n rt_spin_lock+0x40/0x70\n trace_event_buffer_commit+0x2fa/0x4c0\n ? map_vsyscall+0x93/0x93\n trace_event_raw_event_initcall_start+0xbe/0x110\n ? perf_trace_initcall_finish+0x210/0x210\n ? probe_sched_wakeup+0x34/0x40\n ? ttwu_do_wakeup+0xda/0x310\n ? trace_hardirqs_on+0x35/0x170\n ? map_vsyscall+0x93/0x93\n do_one_initcall+0x217/0x3c0\n ? trace_event_raw_event_initcall_level+0x170/0x170\n ? push_cpu_stop+0x400/0x400\n ? cblist_init_generic+0x241/0x290\n kernel_init_freeable+0x1ac/0x347\n ? _raw_spin_unlock_irq+0x65/0x80\n ? rest_init+0xf0/0xf0\n kernel_init+0x1e/0x150\n ret_from_fork+0x22/0x30\n \u003c/TASK\u003e",
"id": "GHSA-9cc8-5cmc-hcj3",
"modified": "2025-04-14T21:32:22Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49322"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1"
}
],
"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-9H35-HQFF-9V3W
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-29 06:31In the Linux kernel, the following vulnerability has been resolved:
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal.
When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.
Lockdep splat:
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); lock(&dev->event_lock);
*** DEADLOCK ***
{
"affected": [],
"aliases": [
"CVE-2026-52946"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:04Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling\n\nA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in\nsend_sigio() and send_sigurg() when a process group receives a signal.\n\nWhen FASYNC is configured for a process group (PIDTYPE_PGID), both\nfunctions use read_lock(\u0026tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -\u003e kill_fasync\n- send_sigurg() via tcp_check_urg -\u003e sk_send_sigurg (NET_RX_SOFTIRQ)\n\nThe deadlock is caused by the rwlock writer fairness mechanism:\n1. CPU 0 (process context) holds read_lock(\u0026tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(\u0026tasklist_lock) in\n fork() or exit() and spins, which blocks all new readers.\n3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).\n4. The softirq calls send_sigurg() and attempts to acquire\n read_lock(\u0026tasklist_lock), deadlocking because CPU 1 is waiting.\n\nSince PID hashing and do_each_pid_task() traversals are already\nRCU-protected, the read_lock on tasklist_lock is no longer strictly\nrequired for safe traversal. Fix this by replacing tasklist_lock with\nrcu_read_lock(), aligning the process group signaling path with the\nsingle-PID path. This also mitigates a potential remote denial of\nservice vector via TCP URG packets.\n\nLockdep splat:\n=====================================================\nWARNING: SOFTIRQ-safe -\u003e SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n \u0026dev-\u003eevent_lock --\u003e \u0026f_owner-\u003elock --\u003e tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(tasklist_lock);\n local_irq_disable();\n lock(\u0026dev-\u003eevent_lock);\n lock(\u0026f_owner-\u003elock);\n \u003cInterrupt\u003e\n lock(\u0026dev-\u003eevent_lock);\n\n*** DEADLOCK ***",
"id": "GHSA-9h35-hqff-9v3w",
"modified": "2026-06-29T06:31:48Z",
"published": "2026-06-24T18:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52946"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00633c4683828acd5256fa8d5163f440d74bbe71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bee417678f1135e35b25a37734db46aa94258d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20a93e397abe850c49b6fa0e8cc827b5f634a8f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32dbd5ce4be3a3ed7e00f8af18795cc84fc50a33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36c1b57b2ecf3c61ac93f5f07bd29b6f21e226ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54626335ea4174ab2d9a183b511d825f6765e47b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897d6a7247739fb1528f98c575df4f2e5de7f994"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5fa9e32fb6718f70c986ee14dd5d01b4846f331"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfcc8e8d8a495bb34cae9e620adfb75fb13a3954"
}
],
"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-9M96-3QWQ-4728
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-23 21:30In the Linux kernel, the following vulnerability has been resolved:
md: fix array_state=clear sysfs deadlock
When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method.
However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject.
That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain.
Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2. Wait briefly for the array to settle, then clear it: sleep 2 echo clear > /sys/block/md0/md/array_state
The warning looks like:
WARNING: possible recursive locking detected bash/588 is trying to acquire lock: (kn->active#65) at __kernfs_remove+0x157/0x1d0 but task is already holding lock: (kn->active#65) at sysfs_unbreak_active_protection+0x1f/0x40 ... Call Trace: kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_write
Restore active protection before mddev_put() so the extra sysfs kobject reference is dropped while the mddev is still held alive. The actual md kobject deletion is then deferred until after the sysfs write path has fully returned.
{
"affected": [],
"aliases": [
"CVE-2026-53125"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix array_state=clear sysfs deadlock\n\nWhen \"clear\" is written to array_state, md_attr_store() breaks sysfs\nactive protection so the array can delete itself from its own sysfs\nstore method.\n\nHowever, md_attr_store() currently drops the mddev reference before\ncalling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0)\nhas made the mddev eligible for delayed deletion, the temporary\nkobject reference taken by sysfs_break_active_protection() can become\nthe last kobject reference protecting the md kobject.\n\nThat allows sysfs_unbreak_active_protection() to drop the last\nkobject reference from the current sysfs writer context. kobject\nteardown then recurses into kernfs removal while the current sysfs\nnode is still being unwound, and lockdep reports recursive locking on\nkn-\u003eactive with kernfs_drain() in the call chain.\n\nReproducer on an existing level:\n1. Create an md0 linear array and activate it:\n mknod /dev/md0 b 9 0\n echo none \u003e /sys/block/md0/md/metadata_version\n echo linear \u003e /sys/block/md0/md/level\n echo 1 \u003e /sys/block/md0/md/raid_disks\n echo \"$(cat /sys/class/block/sdb/dev)\" \u003e /sys/block/md0/md/new_dev\n echo \"$(($(cat /sys/class/block/sdb/size) / 2))\" \u003e \\\n\t/sys/block/md0/md/dev-sdb/size\n echo 0 \u003e /sys/block/md0/md/dev-sdb/slot\n echo active \u003e /sys/block/md0/md/array_state\n2. Wait briefly for the array to settle, then clear it:\n sleep 2\n echo clear \u003e /sys/block/md0/md/array_state\n\nThe warning looks like:\n\n WARNING: possible recursive locking detected\n bash/588 is trying to acquire lock:\n (kn-\u003eactive#65) at __kernfs_remove+0x157/0x1d0\n but task is already holding lock:\n (kn-\u003eactive#65) at sysfs_unbreak_active_protection+0x1f/0x40\n ...\n Call Trace:\n kernfs_drain\n __kernfs_remove\n kernfs_remove_by_name_ns\n sysfs_remove_group\n sysfs_remove_groups\n __kobject_del\n kobject_put\n md_attr_store\n kernfs_fop_write_iter\n vfs_write\n ksys_write\n\nRestore active protection before mddev_put() so the extra sysfs\nkobject reference is dropped while the mddev is still held alive. The\nactual md kobject deletion is then deferred until after the sysfs\nwrite path has fully returned.",
"id": "GHSA-9m96-3qwq-4728",
"modified": "2026-07-23T21:30:35Z",
"published": "2026-06-24T18:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53125"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2aa72276fab9851dbd59c2daeb4b590c5a113908"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62c44566da7493ee48ef17e8507bb798338a07cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92ad0ec509ffb188d8f849b63148664df37b4a52"
}
],
"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-9PHF-M556-W4XG
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: use uninterruptible resv lock for plane updates
virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held():
WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl
Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list.
Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit.
Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO.
Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable.
Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant.
The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences().
{
"affected": [],
"aliases": [
"CVE-2026-64098"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:50Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: use uninterruptible resv lock for plane updates\n\nvirtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock\nthe framebuffer BO\u0027s dma_resv via virtio_gpu_array_lock_resv() and\nignore its return value. The function can fail with -EINTR from\ndma_resv_lock_interruptible() (signal during lock wait) or with\n-ENOMEM from dma_resv_reserve_fences() (fence slot allocation),\nleaving the resv lock not held. The queue path then walks the object\narray and calls dma_resv_add_fence(), which requires the lock held;\nwith lockdep enabled this trips dma_resv_assert_held():\n\n WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840\n Call Trace:\n virtio_gpu_array_add_fence\n virtio_gpu_queue_ctrl_sgs\n virtio_gpu_queue_fenced_ctrl_buffer\n virtio_gpu_cursor_plane_update\n drm_atomic_helper_commit_planes\n drm_atomic_helper_commit_tail\n commit_tail\n drm_atomic_helper_commit\n drm_atomic_commit\n drm_atomic_helper_update_plane\n __setplane_atomic\n drm_mode_cursor_universal\n drm_mode_cursor_common\n drm_mode_cursor_ioctl\n drm_ioctl\n __x64_sys_ioctl\n\nBeyond the WARN, mutating the dma_resv fence list without the lock\nraces with concurrent readers/writers and can corrupt the list.\n\nBoth call sites run inside the .atomic_update plane callback, which\nDRM atomic helpers do not allow to fail (by the time it runs, the\ncommit has been signed off to userspace and there is no clean\nrollback path). Moving the lock acquisition to .prepare_fb was\nrejected because the broader lock scope deadlocks against other BO\nlocking paths in the same atomic commit.\n\nIntroduce virtio_gpu_lock_one_resv_uninterruptible() that uses\ndma_resv_lock() instead of dma_resv_lock_interruptible(). This\neliminates the -EINTR failure mode -- the realistic syzbot trigger\n-- without extending the lock hold across the commit. The helper\nlocks a single BO and rejects nents \u003e 1 with -EINVAL; both fix\nsites lock exactly one BO.\n\nUse it from virtio_gpu_cursor_plane_update() and\nvirtio_gpu_resource_flush(); check the return value to handle the\nremaining -ENOMEM case from dma_resv_reserve_fences() by freeing\nthe objs and skipping the plane update for that frame. The\nframebuffer BOs touched here are not shared with other contexts\nand lock contention is expected to be brief, so the loss of\nsignal-interruptibility is acceptable.\n\nOther callers of virtio_gpu_array_lock_resv() (the ioctl paths)\ncontinue to use the interruptible variant.\n\nThe bug was reported by syzbot, triggered via fault injection\n(fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the\n-ENOMEM branch in dma_resv_reserve_fences().",
"id": "GHSA-9phf-m556-w4xg",
"modified": "2026-07-20T15:31:59Z",
"published": "2026-07-19T18:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64098"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21ab64c77a30d56efc506c8fa2ad8959f8ce3d36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7930eee22cd3df61e85be8aa512032ab303b7167"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8fadd01cf461fee5bb11506621339c548447e5c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9af1b6e175c82daf4b423da339a722d8e67a735a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2359a411b15f495d12cfda6a7db6855ebb7f90f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c86077d512ee980cc91322211d35dbcd3175f64c"
}
],
"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-9PPP-C797-FG56
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-15 15:32In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix af_unix iter deadlock
bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock():
WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0
but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(slock-AF_UNIX); lock(slock-AF_UNIX);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00
Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
{
"affected": [],
"aliases": [
"CVE-2026-53035"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix af_unix iter deadlock\n\nbpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast\npath and the iter prog attempts to update a sockmap. Which ends up spinning\nat sock_map_update_elem()\u0027s bh_lock_sock():\n\nWARNING: possible recursive locking detected\ntest_progs/1393 is trying to acquire lock:\nffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0\n\nbut task is already holding lock:\nffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(slock-AF_UNIX);\n lock(slock-AF_UNIX);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n4 locks held by test_progs/1393:\n #0: ffff88814b59c790 (\u0026p-\u003elock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0\n #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0\n #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0\n #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00\n\nCall Trace:\n dump_stack_lvl+0x5d/0x80\n print_deadlock_bug.cold+0xc0/0xce\n __lock_acquire+0x130f/0x2590\n lock_acquire+0x14e/0x2b0\n _raw_spin_lock+0x30/0x40\n sock_map_update_elem+0xdb/0x1f0\n bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4\n bpf_iter_run_prog+0x5b9/0xb00\n bpf_iter_unix_seq_show+0x1f7/0x2e0\n bpf_seq_read+0x42c/0x10d0\n vfs_read+0x171/0xb20\n ksys_read+0xff/0x200\n do_syscall_64+0x6b/0x3a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e",
"id": "GHSA-9ppp-c797-fg56",
"modified": "2026-07-15T15:32:45Z",
"published": "2026-06-24T18:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53035"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cef33b9813b78f227942572fb317afcd5c9ac94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d328dd695383224aa750ddee6b4ad40c0f8d205"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/527057ebe8076dfbcaef51195ff1b7508646be2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66d9fab4565eafe1afe7ba0581f79b76073b60fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87828b380956d4986f59f2c086e0b09b3e6cdaae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd3592129f24243713673a07225cf1f15a9bb835"
}
],
"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-9PPW-WH7X-2QC9
Vulnerability from github – Published: 2024-12-19 12:32 – Updated: 2024-12-31 21:30The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock.
This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work.
In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region.
{
"affected": [],
"aliases": [
"CVE-2024-45818"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-19T12:15:16Z",
"severity": "MODERATE"
},
"details": "The hypervisor contains code to accelerate VGA memory accesses for HVM\nguests, when the (virtual) VGA is in \"standard\" mode. Locking involved\nthere has an unusual discipline, leaving a lock acquired past the\nreturn from the function that acquired it. This behavior results in a\nproblem when emulating an instruction with two memory accesses, both of\nwhich touch VGA memory (plus some further constraints which aren\u0027t\nrelevant here). When emulating the 2nd access, the lock that is already\nbeing held would be attempted to be re-acquired, resulting in a\ndeadlock.\n\nThis deadlock was already found when the code was first introduced, but\nwas analysed incorrectly and the fix was incomplete. Analysis in light\nof the new finding cannot find a way to make the existing locking\ndiscipline work.\n\nIn staging, this logic has all been removed because it was discovered\nto be accidentally disabled since Xen 4.7. Therefore, we are fixing the\nlocking problem by backporting the removal of most of the feature. Note\nthat even with the feature disabled, the lock would still be acquired\nfor any accesses to the VGA MMIO region.",
"id": "GHSA-9ppw-wh7x-2qc9",
"modified": "2024-12-31T21:30:45Z",
"published": "2024-12-19T12:32:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45818"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-463.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/11/12/2"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-463.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9QMF-MRC9-RWRX
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192eu: Fix deadlock in rtw_joinbss_event_prehandle
There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below:
(Thread 1) | (Thread 2) | _set_timer() rtw_joinbss_event_prehandle()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_join_timeout_handler() | _rtw_join_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...
We hold pmlmepriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtw_joinbss_event_prehandle() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() to spin_lock_irq() in _rtw_join_timeout_handler() in order to prevent deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49303"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192eu: Fix deadlock in rtw_joinbss_event_prehandle\n\nThere is a deadlock in rtw_joinbss_event_prehandle(), which is shown below:\n\n (Thread 1) | (Thread 2)\n | _set_timer()\nrtw_joinbss_event_prehandle()| mod_timer()\n spin_lock_bh() //(1) | (wait a time)\n ... | rtw_join_timeout_handler()\n | _rtw_join_timeout_handler()\n del_timer_sync() | spin_lock_bh() //(2)\n (wait timer to stop) | ...\n\nWe hold pmlmepriv-\u003elock in position (1) of thread 1 and\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need pmlmepriv-\u003elock in position (2) of thread 2.\nAs a result, rtw_joinbss_event_prehandle() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_bh(), which could let timer handler to obtain\nthe needed lock. What`s more, we change spin_lock_bh() to\nspin_lock_irq() in _rtw_join_timeout_handler() in order to\nprevent deadlock.",
"id": "GHSA-9qmf-mrc9-rwrx",
"modified": "2025-04-14T21:32:21Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49303"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fcddf9c7c10202946d5b19409efbdff744fba88"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25cf414b0610fea29d8e045f315648d9007c9a46"
}
],
"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-9RR2-XW5V-W787
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-12-24 18:30In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix soft lockup during fsstress
Below traces are observed during fsstress and system got hung. [ 130.698396] watchdog: BUG: soft lockup - CPU#6 stuck for 26s!
{
"affected": [],
"aliases": [
"CVE-2021-47359"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:22Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix soft lockup during fsstress\n\nBelow traces are observed during fsstress and system got hung.\n[ 130.698396] watchdog: BUG: soft lockup - CPU#6 stuck for 26s!",
"id": "GHSA-9rr2-xw5v-w787",
"modified": "2024-12-24T18:30:48Z",
"published": "2024-05-21T15:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47359"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71826b068884050d5fdd37fda857ba1539c513d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f6c7aff21f81ae8856da1f63847d1362d523409"
}
],
"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-9VC4-746X-P2RF
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-18 15:30In the Linux kernel, the following vulnerability has been resolved:
sfc: fix deadlock in RSS config read
Since cited commit, core locks the net_device's rss_lock when handling ethtool -x command, so driver's implementation should not lock it again. Remove the latter.
{
"affected": [],
"aliases": [
"CVE-2026-23165"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T16:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix deadlock in RSS config read\n\nSince cited commit, core locks the net_device\u0027s rss_lock when handling\n ethtool -x command, so driver\u0027s implementation should not lock it\n again. Remove the latter.",
"id": "GHSA-9vc4-746x-p2rf",
"modified": "2026-03-18T15:30:40Z",
"published": "2026-02-14T18:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23165"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/590c8179ffb01c17644181408821b55b8704c50c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/944c614b0a7afa5b87612c3fb557b95a50ad654c"
}
],
"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-9WMJ-XCGW-57P9
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-05-13 01:22In Lenovo systems, SMM BIOS Write Protection is used to prevent writes to SPI Flash. While this provides sufficient protection, an additional layer of protection is provided by SPI Protected Range Registers (PRx). Lenovo was notified that after resuming from S3 sleep mode in various versions of BIOS for Lenovo systems, the PRx is not set. This does not impact the SMM BIOS Write Protection, which keeps systems protected.
{
"affected": [],
"aliases": [
"CVE-2019-6156"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-10T17:29:00Z",
"severity": "LOW"
},
"details": "In Lenovo systems, SMM BIOS Write Protection is used to prevent writes to SPI Flash. While this provides sufficient protection, an additional layer of protection is provided by SPI Protected Range Registers (PRx). Lenovo was notified that after resuming from S3 sleep mode in various versions of BIOS for Lenovo systems, the PRx is not set. This does not impact the SMM BIOS Write Protection, which keeps systems protected.",
"id": "GHSA-9wmj-xcgw-57p9",
"modified": "2022-05-13T01:22:39Z",
"published": "2022-05-13T01:22:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6156"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/solutions/LEN-26332"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"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.