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.
713 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-9X65-M9RH-PQXF
Vulnerability from github – Published: 2024-04-02 09:30 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
bcachefs: grab s_umount only if snapshotting
When I was testing mongodb over bcachefs with compression, there is a lockdep warning when snapshotting mongodb data volume.
$ cat test.sh prog=bcachefs
$prog subvolume create /mnt/data $prog subvolume create /mnt/data/snapshots
while true;do $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s) sleep 1s done
$ cat /etc/mongodb.conf systemLog: destination: file logAppend: true path: /mnt/data/mongod.log
storage: dbPath: /mnt/data/
lockdep reports: [ 3437.452330] ====================================================== [ 3437.452750] WARNING: possible circular locking dependency detected [ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E [ 3437.453562] ------------------------------------------------------ [ 3437.453981] bcachefs/35533 is trying to acquire lock: [ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190 [ 3437.454875] but task is already holding lock: [ 3437.455268] ffffa0a02b2b10e0 (&type->s_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.456009] which lock already depends on the new lock.
[ 3437.456553] the existing dependency chain (in reverse order) is: [ 3437.457054] -> #3 (&type->s_umount_key#48){.+.+}-{3:3}: [ 3437.457507] down_read+0x3e/0x170 [ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs] [ 3437.458206] __x64_sys_ioctl+0x93/0xd0 [ 3437.458498] do_syscall_64+0x42/0xf0 [ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.459155] -> #2 (&c->snapshot_create_lock){++++}-{3:3}: [ 3437.459615] down_read+0x3e/0x170 [ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs] [ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs] [ 3437.460686] notify_change+0x1f1/0x4a0 [ 3437.461283] do_truncate+0x7f/0xd0 [ 3437.461555] path_openat+0xa57/0xce0 [ 3437.461836] do_filp_open+0xb4/0x160 [ 3437.462116] do_sys_openat2+0x91/0xc0 [ 3437.462402] __x64_sys_openat+0x53/0xa0 [ 3437.462701] do_syscall_64+0x42/0xf0 [ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.463359] -> #1 (&sb->s_type->i_mutex_key#15){+.+.}-{3:3}: [ 3437.463843] down_write+0x3b/0xc0 [ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs] [ 3437.464493] vfs_write+0x21b/0x4c0 [ 3437.464653] ksys_write+0x69/0xf0 [ 3437.464839] do_syscall_64+0x42/0xf0 [ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.465231] -> #0 (sb_writers#10){.+.+}-{0:0}: [ 3437.465471] __lock_acquire+0x1455/0x21b0 [ 3437.465656] lock_acquire+0xc6/0x2b0 [ 3437.465822] mnt_want_write+0x46/0x1a0 [ 3437.465996] filename_create+0x62/0x190 [ 3437.466175] user_path_create+0x2d/0x50 [ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs] [ 3437.466617] __x64_sys_ioctl+0x93/0xd0 [ 3437.466791] do_syscall_64+0x42/0xf0 [ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 3437.467180] other info that might help us debug this:
[ 3437.469670] 2 locks held by bcachefs/35533: other info that might help us debug this:
[ 3437.467507] Chain exists of: sb_writers#10 --> &c->snapshot_create_lock --> &type->s_umount_key#48
[ 3437.467979] Possible unsafe locking scenario:
[ 3437.468223] CPU0 CPU1 [ 3437.468405] ---- ---- [ 3437.468585] rlock(&type->s_umount_key#48); [ 3437.468758] lock(&c->snapshot_create_lock); [ 3437.469030] lock(&type->s_umount_key#48); [ 3437.469291] rlock(sb_writers#10); [ 3437.469434] *** DEADLOCK ***
[ 3437.469 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26658"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-02T07:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcachefs: grab s_umount only if snapshotting\n\nWhen I was testing mongodb over bcachefs with compression,\nthere is a lockdep warning when snapshotting mongodb data volume.\n\n$ cat test.sh\nprog=bcachefs\n\n$prog subvolume create /mnt/data\n$prog subvolume create /mnt/data/snapshots\n\nwhile true;do\n $prog subvolume snapshot /mnt/data /mnt/data/snapshots/$(date +%s)\n sleep 1s\ndone\n\n$ cat /etc/mongodb.conf\nsystemLog:\n destination: file\n logAppend: true\n path: /mnt/data/mongod.log\n\nstorage:\n dbPath: /mnt/data/\n\nlockdep reports:\n[ 3437.452330] ======================================================\n[ 3437.452750] WARNING: possible circular locking dependency detected\n[ 3437.453168] 6.7.0-rc7-custom+ #85 Tainted: G E\n[ 3437.453562] ------------------------------------------------------\n[ 3437.453981] bcachefs/35533 is trying to acquire lock:\n[ 3437.454325] ffffa0a02b2b1418 (sb_writers#10){.+.+}-{0:0}, at: filename_create+0x62/0x190\n[ 3437.454875]\n but task is already holding lock:\n[ 3437.455268] ffffa0a02b2b10e0 (\u0026type-\u003es_umount_key#48){.+.+}-{3:3}, at: bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.456009]\n which lock already depends on the new lock.\n\n[ 3437.456553]\n the existing dependency chain (in reverse order) is:\n[ 3437.457054]\n -\u003e #3 (\u0026type-\u003es_umount_key#48){.+.+}-{3:3}:\n[ 3437.457507] down_read+0x3e/0x170\n[ 3437.457772] bch2_fs_file_ioctl+0x232/0xc90 [bcachefs]\n[ 3437.458206] __x64_sys_ioctl+0x93/0xd0\n[ 3437.458498] do_syscall_64+0x42/0xf0\n[ 3437.458779] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.459155]\n -\u003e #2 (\u0026c-\u003esnapshot_create_lock){++++}-{3:3}:\n[ 3437.459615] down_read+0x3e/0x170\n[ 3437.459878] bch2_truncate+0x82/0x110 [bcachefs]\n[ 3437.460276] bchfs_truncate+0x254/0x3c0 [bcachefs]\n[ 3437.460686] notify_change+0x1f1/0x4a0\n[ 3437.461283] do_truncate+0x7f/0xd0\n[ 3437.461555] path_openat+0xa57/0xce0\n[ 3437.461836] do_filp_open+0xb4/0x160\n[ 3437.462116] do_sys_openat2+0x91/0xc0\n[ 3437.462402] __x64_sys_openat+0x53/0xa0\n[ 3437.462701] do_syscall_64+0x42/0xf0\n[ 3437.462982] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.463359]\n -\u003e #1 (\u0026sb-\u003es_type-\u003ei_mutex_key#15){+.+.}-{3:3}:\n[ 3437.463843] down_write+0x3b/0xc0\n[ 3437.464223] bch2_write_iter+0x5b/0xcc0 [bcachefs]\n[ 3437.464493] vfs_write+0x21b/0x4c0\n[ 3437.464653] ksys_write+0x69/0xf0\n[ 3437.464839] do_syscall_64+0x42/0xf0\n[ 3437.465009] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.465231]\n -\u003e #0 (sb_writers#10){.+.+}-{0:0}:\n[ 3437.465471] __lock_acquire+0x1455/0x21b0\n[ 3437.465656] lock_acquire+0xc6/0x2b0\n[ 3437.465822] mnt_want_write+0x46/0x1a0\n[ 3437.465996] filename_create+0x62/0x190\n[ 3437.466175] user_path_create+0x2d/0x50\n[ 3437.466352] bch2_fs_file_ioctl+0x2ec/0xc90 [bcachefs]\n[ 3437.466617] __x64_sys_ioctl+0x93/0xd0\n[ 3437.466791] do_syscall_64+0x42/0xf0\n[ 3437.466957] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 3437.467180]\n other info that might help us debug this:\n\n[ 3437.469670] 2 locks held by bcachefs/35533:\n other info that might help us debug this:\n\n[ 3437.467507] Chain exists of:\n sb_writers#10 --\u003e \u0026c-\u003esnapshot_create_lock --\u003e \u0026type-\u003es_umount_key#48\n\n[ 3437.467979] Possible unsafe locking scenario:\n\n[ 3437.468223] CPU0 CPU1\n[ 3437.468405] ---- ----\n[ 3437.468585] rlock(\u0026type-\u003es_umount_key#48);\n[ 3437.468758] lock(\u0026c-\u003esnapshot_create_lock);\n[ 3437.469030] lock(\u0026type-\u003es_umount_key#48);\n[ 3437.469291] rlock(sb_writers#10);\n[ 3437.469434]\n *** DEADLOCK ***\n\n[ 3437.469\n---truncated---",
"id": "GHSA-9x65-m9rh-pqxf",
"modified": "2025-02-03T18:30:35Z",
"published": "2024-04-02T09:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26658"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2acc59dd88d27ad69b66ded80df16c042b04eeec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5b41d3fd04c6757b9c2a60a0c5b2609cae9999df"
}
],
"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-9X8P-G64X-M5J5
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-12 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix deadlock between rcu_tasks_trace and event_mutex.
Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace()
There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case.
CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex)
Delegate trace_set_clr_event() to workqueue to avoid such lock dependency.
{
"affected": [],
"aliases": [
"CVE-2025-37884"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock between rcu_tasks_trace and event_mutex.\n\nFix the following deadlock:\nCPU A\n_free_event()\n perf_kprobe_destroy()\n mutex_lock(\u0026event_mutex)\n perf_trace_event_unreg()\n synchronize_rcu_tasks_trace()\n\nThere are several paths where _free_event() grabs event_mutex\nand calls sync_rcu_tasks_trace. Above is one such case.\n\nCPU B\nbpf_prog_test_run_syscall()\n rcu_read_lock_trace()\n bpf_prog_run_pin_on_cpu()\n bpf_prog_load()\n bpf_tracing_func_proto()\n trace_set_clr_event()\n mutex_lock(\u0026event_mutex)\n\nDelegate trace_set_clr_event() to workqueue to avoid\nsuch lock dependency.",
"id": "GHSA-9x8p-g64x-m5j5",
"modified": "2025-11-12T21:31:03Z",
"published": "2025-05-09T09:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37884"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/255cbc9db7067a83713fd2f4b31034ddd266549a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45286680b385f2592db3003554872388dee66d68"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4580f4e0ebdf8dc8d506ae926b88510395a0c1d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5a528a34e1f613565115a7a6016862ccbfcb9ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c5c833f6375f8ecf9254dd27946c927c7d645421"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-9XMP-2MMM-6X5G
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30In binder_release_work of binder.c, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-161151868References: N/A
{
"affected": [],
"aliases": [
"CVE-2020-0423"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-14T14:15:00Z",
"severity": "HIGH"
},
"details": "In binder_release_work of binder.c, there is a possible use-after-free due to improper locking. This could lead to local escalation of privilege in the kernel with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-161151868References: N/A",
"id": "GHSA-9xmp-2mmm-6x5g",
"modified": "2022-05-24T17:30:38Z",
"published": "2022-05-24T17:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0423"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/12/msg00015.html"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2020-10-01"
}
],
"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"
}
]
}
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.