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-MMRM-HWXF-8J92
Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-04-10 15:31In the Linux kernel, the following vulnerability has been resolved:
Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu"
There are reports that the pagetable walker cache coherency is not a given across the spectrum of SDM845/850 devices, leading to lock-ups and resets. It works fine on some devices (like the Dragonboard 845c, but not so much on the Lenovo Yoga C630).
This unfortunately looks like a fluke in firmware development, where likely somewhere in the vast hypervisor stack, a change to accommodate for this was only introduced after the initial software release (which often serves as a baseline for products).
Revert the change to avoid additional guesswork around crashes.
This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.
{
"affected": [],
"aliases": [
"CVE-2025-22012"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T09:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu\"\n\nThere are reports that the pagetable walker cache coherency is not a\ngiven across the spectrum of SDM845/850 devices, leading to lock-ups\nand resets. It works fine on some devices (like the Dragonboard 845c,\nbut not so much on the Lenovo Yoga C630).\n\nThis unfortunately looks like a fluke in firmware development, where\nlikely somewhere in the vast hypervisor stack, a change to accommodate\nfor this was only introduced after the initial software release (which\noften serves as a baseline for products).\n\nRevert the change to avoid additional guesswork around crashes.\n\nThis reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805.",
"id": "GHSA-mmrm-hwxf-8j92",
"modified": "2025-04-10T15:31:48Z",
"published": "2025-04-08T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22012"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e6e9fc90258a318d30b417bcccda908bb82ee9d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f00db31d235946853fb430de8c6aa1295efc8353"
}
],
"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-MPM3-WJP6-8G7X
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2024-11-07 18:31In the Linux kernel, the following vulnerability has been resolved:
mac80211: fix deadlock in AP/VLAN handling
Syzbot reports that when you have AP_VLAN interfaces that are up and close the AP interface they belong to, we get a deadlock. No surprise - since we dev_close() them with the wiphy mutex held, which goes back into the netdev notifier in cfg80211 and tries to acquire the wiphy mutex there.
To fix this, we need to do two things: 1) prevent changing iftype while AP_VLANs are up, we can't easily fix this case since cfg80211 already calls us with the wiphy mutex held, but change_interface() is relatively rare in drivers anyway, so changing iftype isn't used much (and userspace has to fall back to down/change/up anyway) 2) pull the dev_close() loop over VLANs out of the wiphy mutex section in the normal stop case
{
"affected": [],
"aliases": [
"CVE-2021-47225"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix deadlock in AP/VLAN handling\n\nSyzbot reports that when you have AP_VLAN interfaces that are up\nand close the AP interface they belong to, we get a deadlock. No\nsurprise - since we dev_close() them with the wiphy mutex held,\nwhich goes back into the netdev notifier in cfg80211 and tries to\nacquire the wiphy mutex there.\n\nTo fix this, we need to do two things:\n 1) prevent changing iftype while AP_VLANs are up, we can\u0027t\n easily fix this case since cfg80211 already calls us with\n the wiphy mutex held, but change_interface() is relatively\n rare in drivers anyway, so changing iftype isn\u0027t used much\n (and userspace has to fall back to down/change/up anyway)\n 2) pull the dev_close() loop over VLANs out of the wiphy mutex\n section in the normal stop case",
"id": "GHSA-mpm3-wjp6-8g7x",
"modified": "2024-11-07T18:31:20Z",
"published": "2024-05-21T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47225"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8043903fcb72f545c52e3ec74d6fd82ef79ce7c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5befb224edbe53056c2c18999d630dafb4a08b9"
}
],
"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-MVC3-4Q88-Q347
Vulnerability from github – Published: 2025-10-14 21:30 – Updated: 2025-10-14 21:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone
btrfs_can_activate_zone() can be called with the device_list_mutex already held, which will lead to a deadlock:
insert_dev_extents() // Takes device_list_mutex
-> insert_dev_extent()-> btrfs_insert_empty_item()
-> btrfs_insert_empty_items()-> btrfs_search_slot()
-> btrfs_cow_block()-> __btrfs_cow_block()
-> btrfs_alloc_tree_block()-> btrfs_reserve_extent()
-> find_free_extent()-> find_free_extent_update_loop()
-> can_allocate_chunk()-> btrfs_can_activate_zone() // Takes device_list_mutex again
Instead of using the RCU on fs_devices->device_list we can use fs_devices->alloc_list, protected by the chunk_mutex to traverse the list of active devices.
We are in the chunk allocation thread. The newer chunk allocation happens from the devices in the fs_device->alloc_list protected by the chunk_mutex.
btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list)
Also, a device that reappears after the mount won't join the alloc_list yet and, it will be in the dev_list, which we don't want to consider in the context of the chunk alloc.
[15.166572] WARNING: possible recursive locking detected [15.167117] 5.17.0-rc6-dennis #79 Not tainted [15.167487] -------------------------------------------- [15.167733] kworker/u8:3/146 is trying to acquire lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] but task is already holding lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.167733] [15.167733] other info that might help us debug this: [15.167733] Possible unsafe locking scenario: [15.167733] [15.171834] CPU0 [15.171834] ---- [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] [15.171834] *** DEADLOCK *** [15.171834] [15.171834] May be due to missing lock nesting notation [15.171834] [15.171834] 5 locks held by kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs] [15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79 [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] [15.179641] Call Trace: [15.179641] [15.179641] dump_stack_lvl+0x45/0x59 [15.179641] __lock_acquire.cold+0x217/0x2b2 [15.179641] lock_acquire+0xbf/0x2b0 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? lock_is_held_type+0xd7/0x130 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? _raw_spin_unlock+0x24/0x40 [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs] [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs] [15. ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49079"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone\n\nbtrfs_can_activate_zone() can be called with the device_list_mutex already\nheld, which will lead to a deadlock:\n\ninsert_dev_extents() // Takes device_list_mutex\n`-\u003e insert_dev_extent()\n `-\u003e btrfs_insert_empty_item()\n `-\u003e btrfs_insert_empty_items()\n `-\u003e btrfs_search_slot()\n `-\u003e btrfs_cow_block()\n `-\u003e __btrfs_cow_block()\n `-\u003e btrfs_alloc_tree_block()\n `-\u003e btrfs_reserve_extent()\n `-\u003e find_free_extent()\n `-\u003e find_free_extent_update_loop()\n `-\u003e can_allocate_chunk()\n `-\u003e btrfs_can_activate_zone() // Takes device_list_mutex again\n\nInstead of using the RCU on fs_devices-\u003edevice_list we\ncan use fs_devices-\u003ealloc_list, protected by the chunk_mutex to traverse\nthe list of active devices.\n\nWe are in the chunk allocation thread. The newer chunk allocation\nhappens from the devices in the fs_device-\u003ealloc_list protected by the\nchunk_mutex.\n\n btrfs_create_chunk()\n lockdep_assert_held(\u0026info-\u003echunk_mutex);\n gather_device_info\n list_for_each_entry(device, \u0026fs_devices-\u003ealloc_list, dev_alloc_list)\n\nAlso, a device that reappears after the mount won\u0027t join the alloc_list\nyet and, it will be in the dev_list, which we don\u0027t want to consider in\nthe context of the chunk alloc.\n\n [15.166572] WARNING: possible recursive locking detected\n [15.167117] 5.17.0-rc6-dennis #79 Not tainted\n [15.167487] --------------------------------------------\n [15.167733] kworker/u8:3/146 is trying to acquire lock:\n [15.167733] ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs]\n [15.167733]\n [15.167733] but task is already holding lock:\n [15.167733] ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]\n [15.167733]\n [15.167733] other info that might help us debug this:\n [15.167733] Possible unsafe locking scenario:\n [15.167733]\n [15.171834] CPU0\n [15.171834] ----\n [15.171834] lock(\u0026fs_devs-\u003edevice_list_mutex);\n [15.171834] lock(\u0026fs_devs-\u003edevice_list_mutex);\n [15.171834]\n [15.171834] *** DEADLOCK ***\n [15.171834]\n [15.171834] May be due to missing lock nesting notation\n [15.171834]\n [15.171834] 5 locks held by kworker/u8:3/146:\n [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0\n [15.171834] #1: ffffc9000067be80 ((work_completion)(\u0026fs_info-\u003easync_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0\n [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs]\n [15.176244] #3: ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]\n [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs]\n [15.179641]\n [15.179641] stack backtrace:\n [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79\n [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014\n [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]\n [15.179641] Call Trace:\n [15.179641] \u003cTASK\u003e\n [15.179641] dump_stack_lvl+0x45/0x59\n [15.179641] __lock_acquire.cold+0x217/0x2b2\n [15.179641] lock_acquire+0xbf/0x2b0\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] __mutex_lock+0x8e/0x970\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] ? lock_is_held_type+0xd7/0x130\n [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] find_free_extent+0x15a/0x14f0 [btrfs]\n [15.183838] ? _raw_spin_unlock+0x24/0x40\n [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs]\n [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs]\n [15.\n---truncated---",
"id": "GHSA-mvc3-4q88-q347",
"modified": "2025-10-14T21:30:25Z",
"published": "2025-10-14T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49079"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09e65ae515af2b24d6dc23af21719a3b41de83e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b9e66762aa0cda2a9c2d5542d64e04dac528fa6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/142f822bd945a7be442a2916ec6167cc102c4183"
}
],
"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-MVGM-595C-W457
Vulnerability from github – Published: 2024-03-18 12:30 – Updated: 2026-07-24 15:31In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
idev->mc_ifc_count can be written over without proper locking.
Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations.
[1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work
write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ...
write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...
{
"affected": [],
"aliases": [
"CVE-2024-26631"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-18T11:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work\n\nidev-\u003emc_ifc_count can be written over without proper locking.\n\nOriginally found by syzbot [1], fix this issue by encapsulating calls\nto mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with\nmutex_lock() and mutex_unlock() accordingly as these functions\nshould only be called with mc_lock per their declarations.\n\n[1]\nBUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work\n\nwrite to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:\n mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]\n ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725\n addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949\n addrconf_notify+0x310/0x980\n notifier_call_chain kernel/notifier.c:93 [inline]\n raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461\n __dev_notify_flags+0x205/0x3d0\n dev_change_flags+0xab/0xd0 net/core/dev.c:8685\n do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916\n rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]\n __rtnl_newlink net/core/rtnetlink.c:3717 [inline]\n rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754\n rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558\n netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545\n rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910\n ...\n\nwrite to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:\n mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653\n process_one_work kernel/workqueue.c:2627 [inline]\n process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700\n worker_thread+0x525/0x730 kernel/workqueue.c:2781\n ...",
"id": "GHSA-mvgm-595c-w457",
"modified": "2026-07-24T15:31:45Z",
"published": "2024-03-18T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26631"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75ddcd741d2a30696f5893bc71a9d28f4ef22311"
}
],
"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-MVJQ-GQ62-VXRR
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 00:31In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix potential deadlock in cpu hotplug with osnoise
The following sequence may leads deadlock in cpu hotplug:
task1 task2 task3
----- ----- -----
mutex_lock(&interface_lock)
[CPU GOING OFFLINE]
cpus_write_lock();
osnoise_cpu_die();
kthread_stop(task3);
wait_for_completion();
osnoise_sleep();
mutex_lock(&interface_lock);
cpus_read_lock();
[DEAD LOCK]
Fix by swap the order of cpus_read_lock() and mutex_lock(&interface_lock).
{
"affected": [],
"aliases": [
"CVE-2026-31480"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:45Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix potential deadlock in cpu hotplug with osnoise\n\nThe following sequence may leads deadlock in cpu hotplug:\n\n task1 task2 task3\n ----- ----- -----\n\n mutex_lock(\u0026interface_lock)\n\n [CPU GOING OFFLINE]\n\n cpus_write_lock();\n osnoise_cpu_die();\n kthread_stop(task3);\n wait_for_completion();\n\n osnoise_sleep();\n mutex_lock(\u0026interface_lock);\n\n cpus_read_lock();\n\n [DEAD LOCK]\n\nFix by swap the order of cpus_read_lock() and mutex_lock(\u0026interface_lock).",
"id": "GHSA-mvjq-gq62-vxrr",
"modified": "2026-04-28T00:31:40Z",
"published": "2026-04-22T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31480"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03474a01c199de17a8e2d39b51df6beb9c76e831"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f9885732248d22f788e4992c739a98c88ab8a55"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a41d4633cd2c15eb5ed31e8f3b16910e50a8c9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7aa095ce7d224308cb6979956f0de8607df93d4f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf929c21eeed5bd39873fb14bfdfff963fa6f1da"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef41a85a55022e27cdaebf22a6676910b66f65aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f278b8ebf7eba2a1699cfc7bf30dd3ef898d60d7"
}
],
"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-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"
}
]
}
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.