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.
720 vulnerabilities reference this CWE, most recent first.
GHSA-MW57-63XV-7MX2
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2026-02-19 18:31In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()
Callers of wdev_chandef() must hold the wiphy mutex.
But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes:
WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985
{
"affected": [],
"aliases": [
"CVE-2025-38643"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()\n\nCallers of wdev_chandef() must hold the wiphy mutex.\n\nBut the worker cfg80211_propagate_cac_done_wk() never takes the lock.\nWhich triggers the warning below with the mesh_peer_connected_dfs\ntest from hostapd and not (yet) released mac80211 code changes:\n\nWARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165\nModules linked in:\nCPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf\nWorkqueue: cfg80211 cfg80211_propagate_cac_done_wk\nStack:\n 00000000 00000001 ffffff00 6093267c\n 00000000 6002ec30 6d577c50 60037608\n 00000000 67e8d108 6063717b 00000000\nCall Trace:\n [\u003c6002ec30\u003e] ? _printk+0x0/0x98\n [\u003c6003c2b3\u003e] show_stack+0x10e/0x11a\n [\u003c6002ec30\u003e] ? _printk+0x0/0x98\n [\u003c60037608\u003e] dump_stack_lvl+0x71/0xb8\n [\u003c6063717b\u003e] ? wdev_chandef+0x60/0x165\n [\u003c6003766d\u003e] dump_stack+0x1e/0x20\n [\u003c6005d1b7\u003e] __warn+0x101/0x20f\n [\u003c6005d3a8\u003e] warn_slowpath_fmt+0xe3/0x15d\n [\u003c600b0c5c\u003e] ? mark_lock.part.0+0x0/0x4ec\n [\u003c60751191\u003e] ? __this_cpu_preempt_check+0x0/0x16\n [\u003c600b11a2\u003e] ? mark_held_locks+0x5a/0x6e\n [\u003c6005d2c5\u003e] ? warn_slowpath_fmt+0x0/0x15d\n [\u003c60052e53\u003e] ? unblock_signals+0x3a/0xe7\n [\u003c60052f2d\u003e] ? um_set_signals+0x2d/0x43\n [\u003c60751191\u003e] ? __this_cpu_preempt_check+0x0/0x16\n [\u003c607508b2\u003e] ? lock_is_held_type+0x207/0x21f\n [\u003c6063717b\u003e] wdev_chandef+0x60/0x165\n [\u003c605f89b4\u003e] regulatory_propagate_dfs_state+0x247/0x43f\n [\u003c60052f00\u003e] ? um_set_signals+0x0/0x43\n [\u003c605e6bfd\u003e] cfg80211_propagate_cac_done_wk+0x3a/0x4a\n [\u003c6007e460\u003e] process_scheduled_works+0x3bc/0x60e\n [\u003c6007d0ec\u003e] ? move_linked_works+0x4d/0x81\n [\u003c6007d120\u003e] ? assign_work+0x0/0xaa\n [\u003c6007f81f\u003e] worker_thread+0x220/0x2dc\n [\u003c600786ef\u003e] ? set_pf_worker+0x0/0x57\n [\u003c60087c96\u003e] ? to_kthread+0x0/0x43\n [\u003c6008ab3c\u003e] kthread+0x2d3/0x2e2\n [\u003c6007f5ff\u003e] ? worker_thread+0x0/0x2dc\n [\u003c6006c05b\u003e] ? calculate_sigpending+0x0/0x56\n [\u003c6003b37d\u003e] new_thread_handler+0x4a/0x64\nirq event stamp: 614611\nhardirqs last enabled at (614621): [\u003c00000000600bc96b\u003e] __up_console_sem+0x82/0xaf\nhardirqs last disabled at (614630): [\u003c00000000600bc92c\u003e] __up_console_sem+0x43/0xaf\nsoftirqs last enabled at (614268): [\u003c00000000606c55c6\u003e] __ieee80211_wake_queue+0x933/0x985\nsoftirqs last disabled at (614266): [\u003c00000000606c52d6\u003e] __ieee80211_wake_queue+0x643/0x985",
"id": "GHSA-mw57-63xv-7mx2",
"modified": "2026-02-19T18:31:42Z",
"published": "2025-08-22T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38643"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c5dee15239f3f3e31aa5c8808f18996c039e2c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a63523d3541eef4cf504a9682e6fbe94ffe79a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7022df2248c08c6f75a01714163ac902333bf3db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3d24038eb775f2f7a1dfef58d8e1dc444a12820"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbce810607726408f889d3358f4780fd1436861e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/defe9ce121160788547e8e6ec4438ad8a14f40dd"
}
],
"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-MX24-9C8C-52XX
Vulnerability from github – Published: 2024-03-03 00:30 – Updated: 2025-01-13 21:30In the Linux kernel, the following vulnerability has been resolved:
phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers
The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking.
Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers.
{
"affected": [],
"aliases": [
"CVE-2023-52505"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T22:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nphy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers\n\nThe protocol converter configuration registers PCC8, PCCC, PCCD\n(implemented by the driver), as well as others, control protocol\nconverters from multiple lanes (each represented as a different\nstruct phy). So, if there are simultaneous calls to phy_set_mode_ext()\nto lanes sharing the same PCC register (either for the \"old\" or for the\n\"new\" protocol), corruption of the values programmed to hardware is\npossible, because lynx_28g_rmw() has no locking.\n\nAdd a spinlock in the struct lynx_28g_priv shared by all lanes, and take\nthe global spinlock from the phy_ops :: set_mode() implementation. There\nare no other callers which modify PCC registers.",
"id": "GHSA-mx24-9c8c-52xx",
"modified": "2025-01-13T21:30:46Z",
"published": "2024-03-03T00:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52505"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/139ad1143151a07be93bf741d4ea7c89e59f89ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f901f8448c6b25ed843796b114471d2a3fc5dfb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c2d7c79898b427d263c64a4841987eec131f2d4e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MXQG-5WMF-7C29
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-28 15:30In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Fix global state lock backoff
We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0.
Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged in CI:
WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0
Patchwork: https://patchwork.freedesktop.org/patch/492701/
{
"affected": [],
"aliases": [
"CVE-2022-50173"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/mdp5: Fix global state lock backoff\n\nWe need to grab the lock after the early return for !hwpipe case.\nOtherwise, we could have hit contention yet still returned 0.\n\nFixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged\nin CI:\n\n WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154\n Modules linked in:\n CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1\n Hardware name: Qualcomm Technologies, Inc. DB820c (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : drm_modeset_lock+0xf8/0x154\n lr : drm_atomic_get_private_obj_state+0x84/0x170\n sp : ffff80000cfab6a0\n x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00\n x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58\n x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001\n x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038\n x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0\n x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47\n x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610\n x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000\n x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029\n x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58\n Call trace:\n drm_modeset_lock+0xf8/0x154\n drm_atomic_get_private_obj_state+0x84/0x170\n mdp5_get_global_state+0x54/0x6c\n mdp5_pipe_release+0x2c/0xd4\n mdp5_plane_atomic_check+0x2ec/0x414\n drm_atomic_helper_check_planes+0xd8/0x210\n drm_atomic_helper_check+0x54/0xb0\n ...\n ---[ end trace 0000000000000000 ]---\n drm_modeset_lock attempting to lock a contended lock without backoff:\n drm_modeset_lock+0x148/0x154\n mdp5_get_global_state+0x30/0x6c\n mdp5_pipe_release+0x2c/0xd4\n mdp5_plane_atomic_check+0x290/0x414\n drm_atomic_helper_check_planes+0xd8/0x210\n drm_atomic_helper_check+0x54/0xb0\n drm_atomic_check_only+0x4b0/0x8f4\n drm_atomic_commit+0x68/0xe0\n\nPatchwork: https://patchwork.freedesktop.org/patch/492701/",
"id": "GHSA-mxqg-5wmf-7c29",
"modified": "2025-11-28T15:30:28Z",
"published": "2025-06-18T12:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50173"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b07f28c23ff50a7fa5dbc3f6b3b6bd53ac9fc70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/247f2934324f9a18d18df24ea4bfcc7d4631d0ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e34d6c8180a398de6448a93df25068bf3062042"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2fdf5a54ef9376ff69149a48c5616f1141008c9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92ef86ab513593c6329d04146e61f9a670e72fc5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf386c955f35a0a01bef482b6035d40ff2f6cc75"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4e3a8c7e890049e7ba2b49ad0315dae841dfa55"
}
],
"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-MXVQ-QHX2-FP47
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-04-27 15:30In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - fix circular locking dependency with ff-core
A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller):
ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
The cycle is caused by four lock acquisition paths:
-
ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex.
-
device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex.
-
device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex.
-
evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes.
To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock.
Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible.
Lock ordering after the fix:
ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)
{
"affected": [],
"aliases": [
"CVE-2026-31667"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:46Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: uinput - fix circular locking dependency with ff-core\n\nA lockdep circular locking dependency warning can be triggered\nreproducibly when using a force-feedback gamepad with uinput (for\nexample, playing ELDEN RING under Wine with a Flydigi Vader 5\ncontroller):\n\n ff-\u003emutex -\u003e udev-\u003emutex -\u003e input_mutex -\u003e dev-\u003emutex -\u003e ff-\u003emutex\n\nThe cycle is caused by four lock acquisition paths:\n\n1. ff upload: input_ff_upload() holds ff-\u003emutex and calls\n uinput_dev_upload_effect() -\u003e uinput_request_submit() -\u003e\n uinput_request_send(), which acquires udev-\u003emutex.\n\n2. device create: uinput_ioctl_handler() holds udev-\u003emutex and calls\n uinput_create_device() -\u003e input_register_device(), which acquires\n input_mutex.\n\n3. device register: input_register_device() holds input_mutex and\n calls kbd_connect() -\u003e input_register_handle(), which acquires\n dev-\u003emutex.\n\n4. evdev release: evdev_release() calls input_flush_device() under\n dev-\u003emutex, which calls input_ff_flush() acquiring ff-\u003emutex.\n\nFix this by introducing a new state_lock spinlock to protect\nudev-\u003estate and udev-\u003edev access in uinput_request_send() instead of\nacquiring udev-\u003emutex. The function only needs to atomically check\ndevice state and queue an input event into the ring buffer via\nuinput_dev_event() -- both operations are safe under a spinlock\n(ktime_get_ts64() and wake_up_interruptible() do not sleep). This\nbreaks the ff-\u003emutex -\u003e udev-\u003emutex link since a spinlock is a leaf in\nthe lock ordering and cannot form cycles with mutexes.\n\nTo keep state transitions visible to uinput_request_send(), protect\nwrites to udev-\u003estate in uinput_create_device() and\nuinput_destroy_device() with the same state_lock spinlock.\n\nAdditionally, move init_completion(\u0026request-\u003edone) from\nuinput_request_send() to uinput_request_submit() before\nuinput_request_reserve_slot(). Once the slot is allocated,\nuinput_flush_requests() may call complete() on it at any time from\nthe destroy path, so the completion must be initialised before the\nrequest becomes visible.\n\nLock ordering after the fix:\n\n ff-\u003emutex -\u003e state_lock (spinlock, leaf)\n udev-\u003emutex -\u003e state_lock (spinlock, leaf)\n udev-\u003emutex -\u003e input_mutex -\u003e dev-\u003emutex -\u003e ff-\u003emutex (no back-edge)",
"id": "GHSA-mxvq-qhx2-fp47",
"modified": "2026-04-27T15:30:46Z",
"published": "2026-04-24T15:32:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31667"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1534661043c434b81cfde26b97a2fb2460329cf0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e09dfbb4f5d20ee111f92325a00f85778a5f328"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/271ee71a1917b89f6d73ec82dd091c33d92ee617"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4cda78d6f8bf2b700529f2fbccb994c3e826d7c2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/546c18a14924eb521fe168d916d7ce28f1e13c1d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71a9729f412e2c692a35c542e14b706fb342927f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/974f7b138c3a96dd5cd53d1b33409cd7b2229dc6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3d6c9c053c9c605651508569230ead633b13f76"
}
],
"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-P22Q-5W3Q-WQPQ
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
spi: spidev: fix lock inversion between spi_lock and buf_lock
The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:
write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock
This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:
WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***
The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.
Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.
buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.
This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.
{
"affected": [],
"aliases": [
"CVE-2026-43319"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:40Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spidev: fix lock inversion between spi_lock and buf_lock\n\nThe spidev driver previously used two mutexes, spi_lock and buf_lock,\nbut acquired them in different orders depending on the code path:\n\n write()/read(): buf_lock -\u003e spi_lock\n ioctl(): spi_lock -\u003e buf_lock\n\nThis AB-BA locking pattern triggers lockdep warnings and can\ncause real deadlocks:\n\n WARNING: possible circular locking dependency detected\n spidev_ioctl() -\u003e mutex_lock(\u0026spidev-\u003ebuf_lock)\n spidev_sync_write() -\u003e mutex_lock(\u0026spidev-\u003espi_lock)\n *** DEADLOCK ***\n\nThe issue is reproducible with a simple userspace program that\nperforms write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from\nseparate threads on the same spidev file descriptor.\n\nFix this by simplifying the locking model and removing the lock\ninversion entirely. spidev_sync() no longer performs any locking,\nand all callers serialize access using spi_lock.\n\nbuf_lock is removed since its functionality is fully covered by\nspi_lock, eliminating the possibility of lock ordering issues.\n\nThis removes the lock inversion and prevents deadlocks without\nchanging userspace ABI or behaviour.",
"id": "GHSA-p22q-5w3q-wqpq",
"modified": "2026-06-01T18:31:30Z",
"published": "2026-05-08T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43319"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40534d19ed2afb880ecf202dab26a8e7a5808d16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/41ccfac7d302968a4f32b5f7b012d066c5f5cdf8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e341e18215030af2136836b78508e0d798916df7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8431b8672231d378b03176fe74c95adfd3522cf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fabfed1afe273717ea33b8aee46b767360edbb80"
}
],
"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-P237-W2MF-8CWM
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
netrom: fix possible dead-lock in nr_rt_ioctl()
syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
[1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock);
*** DEADLOCK ***
1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-38589"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: fix possible dead-lock in nr_rt_ioctl()\n\nsyzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]\n\nMake sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)\n\n[1]\nWARNING: possible circular locking dependency detected\n6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted\n------------------------------------------------------\nsyz-executor350/5129 is trying to acquire lock:\n ffff8880186e2070 (\u0026nr_node-\u003enode_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n ffff8880186e2070 (\u0026nr_node-\u003enode_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]\n ffff8880186e2070 (\u0026nr_node-\u003enode_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]\n ffff8880186e2070 (\u0026nr_node-\u003enode_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697\n\nbut task is already holding lock:\n ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]\n ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (nr_node_list_lock){+...}-{2:2}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754\n __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]\n _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n nr_remove_node net/netrom/nr_route.c:299 [inline]\n nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355\n nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683\n sock_do_ioctl+0x158/0x460 net/socket.c:1222\n sock_ioctl+0x629/0x8e0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n-\u003e #0 (\u0026nr_node-\u003enode_lock){+...}-{2:2}:\n check_prev_add kernel/locking/lockdep.c:3134 [inline]\n check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869\n __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754\n __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]\n _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n nr_node_lock include/net/netrom.h:152 [inline]\n nr_dec_obs net/netrom/nr_route.c:464 [inline]\n nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697\n sock_do_ioctl+0x158/0x460 net/socket.c:1222\n sock_ioctl+0x629/0x8e0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(nr_node_list_lock);\n lock(\u0026nr_node-\u003enode_lock);\n lock(nr_node_list_lock);\n lock(\u0026nr_node-\u003enode_lock);\n\n *** DEADLOCK ***\n\n1 lock held by syz-executor350/5129:\n #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]\n #0: ffffffff8f70\n---truncated---",
"id": "GHSA-p237-w2mf-8cwm",
"modified": "2026-05-12T12:31:55Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38589"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P293-2W9F-JRWC
Vulnerability from github – Published: 2022-05-26 00:01 – Updated: 2024-05-03 00:30MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (pthread_create returns a nonzero value) while executing the method create_worker_threads, the held lock is not released correctly, which allows local users to trigger a denial of service due to the deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-31622"
],
"database_specific": {
"cwe_ids": [
"CWE-404",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-25T21:15:00Z",
"severity": "MODERATE"
},
"details": "MariaDB Server before 10.7 is vulnerable to Denial of Service. In extra/mariabackup/ds_compress.cc, when an error occurs (pthread_create returns a nonzero value) while executing the method create_worker_threads, the held lock is not released correctly, which allows local users to trigger a denial of service due to the deadlock.",
"id": "GHSA-p293-2w9f-jrwc",
"modified": "2024-05-03T00:30:43Z",
"published": "2022-05-26T00:01:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31622"
},
{
"type": "WEB",
"url": "https://github.com/MariaDB/server/commit/e1eb39a446c30b8459c39fd7f2ee1c55a36e97d2"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26561"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26561?filter=-2"
},
{
"type": "WEB",
"url": "https://jira.mariadb.org/browse/MDEV-26574"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220707-0006"
}
],
"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-P2QG-CV6R-5429
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2024-03-21 03:33gssproxy (aka gss-proxy) before 0.8.3 does not unlock cond_mutex before pthread exit in gp_worker_main() in gp_workers.c.
{
"affected": [],
"aliases": [
"CVE-2020-12658"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-31T01:15:00Z",
"severity": "CRITICAL"
},
"details": "gssproxy (aka gss-proxy) before 0.8.3 does not unlock cond_mutex before pthread exit in gp_worker_main() in gp_workers.c.",
"id": "GHSA-p2qg-cv6r-5429",
"modified": "2024-03-21T03:33:56Z",
"published": "2022-05-24T17:37:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12658"
},
{
"type": "WEB",
"url": "https://github.com/gssapi/gssproxy/commit/cb761412e299ef907f22cd7c4146d50c8a792003"
},
{
"type": "WEB",
"url": "https://github.com/gssapi/gssproxy/compare/v0.8.2...v0.8.3"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/01/msg00004.html"
},
{
"type": "WEB",
"url": "https://pagure.io/gssproxy/c/cb761412e299ef907f22cd7c4146d50c8a792003?branch=master"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P2W9-GVCM-4PX8
Vulnerability from github – Published: 2025-12-31 21:30 – Updated: 2026-02-02 21:30ZwiiCMS versions prior to 13.7.00 contain a denial-of-service vulnerability in multiple administrative endpoints due to improper authorization checks combined with flawed resource state management. When an authenticated low-privilege user requests an administrative page, the application returns "404 Not Found" as expected, but incorrectly acquires and associates a temporary lock on the targeted resource with the attacker session prior to authorization. This lock prevents other users, including administrators, from accessing the affected functionality until the attacker navigates away or the session is terminated.
{
"affected": [],
"aliases": [
"CVE-2025-34467"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-31T19:15:43Z",
"severity": "MODERATE"
},
"details": "ZwiiCMS\u00a0versions prior to\u00a013.7.00 contain a denial-of-service vulnerability in multiple administrative endpoints due to improper authorization checks combined with flawed resource state management. When an authenticated low-privilege user requests an administrative page, the application returns \"404 Not Found\" as expected, but incorrectly acquires and associates a temporary lock on the targeted resource with the attacker session prior to authorization. This lock prevents other users, including administrators, from accessing the affected functionality until the attacker navigates away or the session is terminated.",
"id": "GHSA-p2w9-gvcm-4px8",
"modified": "2026-02-02T21:30:21Z",
"published": "2025-12-31T21:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34467"
},
{
"type": "WEB",
"url": "https://codeberg.org/fredtempez/ZwiiCMS/releases/tag/13.7.00"
},
{
"type": "WEB",
"url": "https://github.com/fredtempez/ZwiiCMS"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/zwiicms-lock-persistence-authenticated-dos-against-administrative-pages"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-P357-Q4PH-XR92
Vulnerability from github – Published: 2024-09-18 09:30 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix qgroup reserve leaks in cow_file_range
In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent.
Therefore, any errors that occur before the ordered_extent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cow_file_range where we fail to get to allocating the ordered extent. Note that because we do clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path.
This results in failures at the unmount stage of the test that look like:
BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? report_bug+0xff/0x140 ? handle_bug+0x3b/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? close_ctree+0x222/0x4d0 [btrfs] generic_shutdown_super+0x70/0x160 kill_anon_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] deactivate_locked_super+0x2e/0xa0 cleanup_mnt+0xb5/0x150 task_work_run+0x57/0x80 syscall_exit_to_user_mode+0x121/0x130 do_syscall_64+0xab/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked
Cases 2 and 3 in the out_reserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfs_free_qgroup_data.
{
"affected": [],
"aliases": [
"CVE-2024-46733"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-18T07:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix qgroup reserve leaks in cow_file_range\n\nIn the buffered write path, the dirty page owns the qgroup reserve until\nit creates an ordered_extent.\n\nTherefore, any errors that occur before the ordered_extent is created\nmust free that reservation, or else the space is leaked. The fstest\ngeneric/475 exercises various IO error paths, and is able to trigger\nerrors in cow_file_range where we fail to get to allocating the ordered\nextent. Note that because we *do* clear delalloc, we are likely to\nremove the inode from the delalloc list, so the inodes/pages to not have\ninvalidate/launder called on them in the commit abort path.\n\nThis results in failures at the unmount stage of the test that look like:\n\n BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure\n BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure\n BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672\n ------------[ cut here ]------------\n WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]\n Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq\n CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]\n RSP: 0018:ffffb4465283be00 EFLAGS: 00010202\n RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001\n RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8\n RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000\n R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c\n R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0\n Call Trace:\n \u003cTASK\u003e\n ? close_ctree+0x222/0x4d0 [btrfs]\n ? __warn.cold+0x8e/0xea\n ? close_ctree+0x222/0x4d0 [btrfs]\n ? report_bug+0xff/0x140\n ? handle_bug+0x3b/0x70\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? close_ctree+0x222/0x4d0 [btrfs]\n generic_shutdown_super+0x70/0x160\n kill_anon_super+0x11/0x40\n btrfs_kill_super+0x11/0x20 [btrfs]\n deactivate_locked_super+0x2e/0xa0\n cleanup_mnt+0xb5/0x150\n task_work_run+0x57/0x80\n syscall_exit_to_user_mode+0x121/0x130\n do_syscall_64+0xab/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f916847a887\n ---[ end trace 0000000000000000 ]---\n BTRFS error (device dm-8 state EA): qgroup reserved space leaked\n\nCases 2 and 3 in the out_reserve path both pertain to this type of leak\nand must free the reserved qgroup data. Because it is already an error\npath, I opted not to handle the possible errors in\nbtrfs_free_qgroup_data.",
"id": "GHSA-p357-q4ph-xr92",
"modified": "2025-11-03T21:31:13Z",
"published": "2024-09-18T09:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46733"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/159f0f61b283ea71e827dd0c18c5dce197de1fa2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30479f31d44d47ed00ae0c7453d9b253537005b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84464db2ec2a55b9313d5f264da196a37ec80994"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e42ef22bc10f0309c0c65d8d6ca8b4127a674b7f"
},
{
"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"
}
]
}
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.