CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
729 vulnerabilities reference this CWE, most recent first.
GHSA-26P5-HWVM-HF8M
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
ath11k: Fix frames flush failure caused by deadlock
We are seeing below warnings:
kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0
this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work has no chance to run in 5 seconds.
By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing ATH11K_FLUSH_TIMEOUT to 50 we get below warnings:
kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds. kernel: [ 120.763169] Not tainted 5.10.90 #12 kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0 kernel: [ 120.763201] Call Trace: kernel: [ 120.763214] __schedule+0x785/0x12fa kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb kernel: [ 120.763242] schedule+0x7e/0xa1 kernel: [ 120.763253] schedule_timeout+0x98/0xfe kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a] kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2 kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763802] ? genl_rcv+0x36/0x36 kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7 kernel: [ 120.763829] genl_rcv+0x28/0x36 kernel: [ 120.763840] netlink_unicast+0x179/0x24b kernel: [ 120.763854] netlink_sendmsg+0x393/0x401 kernel: [ 120.763872] sock_sendmsg+0x72/0x76 kernel: [ 120.763886] _syssendmsg+0x170/0x1e6 kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2 kernel: [ 120.763914] _sys_sendmsg+0x95/0xd1 kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf kernel: [ 120.763956] do_syscall_64+0x43/0x55 kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83 kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83 kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009 kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000 kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980 kernel: [ 120.764032] R13: 00007ffe604 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2022-49123"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:00:49Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: Fix frames flush failure caused by deadlock\n\nWe are seeing below warnings:\n\nkernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0\nkernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0\nkernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0\n\nthis means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work\nhas no chance to run in 5 seconds.\n\nBy setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing\nATH11K_FLUSH_TIMEOUT to 50 we get below warnings:\n\nkernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.\nkernel: [ 120.763169] Not tainted 5.10.90 #12\nkernel: [ 120.763177] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\nkernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0\nkernel: [ 120.763201] Call Trace:\nkernel: [ 120.763214] __schedule+0x785/0x12fa\nkernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb\nkernel: [ 120.763242] schedule+0x7e/0xa1\nkernel: [ 120.763253] schedule_timeout+0x98/0xfe\nkernel: [ 120.763266] ? run_local_timers+0x4a/0x4a\nkernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]\nkernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e\nkernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]\nkernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2\nkernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]\nkernel: [ 120.763802] ? genl_rcv+0x36/0x36\nkernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7\nkernel: [ 120.763829] genl_rcv+0x28/0x36\nkernel: [ 120.763840] netlink_unicast+0x179/0x24b\nkernel: [ 120.763854] netlink_sendmsg+0x393/0x401\nkernel: [ 120.763872] sock_sendmsg+0x72/0x76\nkernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6\nkernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2\nkernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1\nkernel: [ 120.763940] __sys_sendmsg+0x85/0xbf\nkernel: [ 120.763956] do_syscall_64+0x43/0x55\nkernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9\nkernel: [ 120.763977] RIP: 0033:0x79089f3fcc83\nkernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nkernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83\nkernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009\nkernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000\nkernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980\nkernel: [ 120.764032] R13: 00007ffe604\n---truncated---",
"id": "GHSA-26p5-hwvm-hf8m",
"modified": "2025-03-14T00:30:49Z",
"published": "2025-03-14T00:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49123"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/261b07519518bd14cb168b287b17e1d195f8d0c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33e723dc054edfc94da90eecca3b72cb424ce4a3"
}
],
"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-26QQ-FQ9W-JRJ5
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-21 18:30In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: fix deadlock in remain-on-channel
mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock.
Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue.
{
"affected": [],
"aliases": [
"CVE-2026-53100"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:24Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: fix deadlock in remain-on-channel\n\nmt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel()\nwhile already holding dev-\u003emutex. Since mt76_set_channel() also acquires\ndev-\u003emutex, this results in a deadlock.\n\nUse __mt76_set_channel() instead of mt76_set_channel().\nAdd cancel_delayed_work_sync() for mac_work before acquiring the mutex\nin mt76_remain_on_channel() to prevent a secondary deadlock with the\nmac_work workqueue.",
"id": "GHSA-26qq-fq9w-jrj5",
"modified": "2026-07-21T18:30:42Z",
"published": "2026-06-24T18:32:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53100"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5fc8c5d45e44575dda9fcabdc2aac4ad97baf0cd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6939b97ddad3cf3dfbb3b5a0a12ef79cb886747e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7a89c245d203aa0ed5ff2d68ac05b48b2ef9fa3f"
}
],
"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-276P-5GR8-Q5FQ
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-11-27 21:32In the Linux kernel, the following vulnerability has been resolved:
mptcp: init: protect sched with rcu_read_lock
Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created:
============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted
net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176.
stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfxsyssocket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.
{
"affected": [],
"aliases": [
"CVE-2024-53047"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: init: protect sched with rcu_read_lock\n\nEnabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT\ncreates this splat when an MPTCP socket is created:\n\n =============================\n WARNING: suspicious RCU usage\n 6.12.0-rc2+ #11 Not tainted\n -----------------------------\n net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n no locks held by mptcp_connect/176.\n\n stack backtrace:\n CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11\n Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl (lib/dump_stack.c:123)\n lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)\n mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7))\n mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1))\n ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28)\n inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386)\n ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1))\n __sock_create (net/socket.c:1576)\n __sys_socket (net/socket.c:1671)\n ? __pfx___sys_socket (net/socket.c:1712)\n ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1))\n __x64_sys_socket (net/socket.c:1728)\n do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nThat\u0027s because when the socket is initialised, rcu_read_lock() is not\nused despite the explicit comment written above the declaration of\nmptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the\nwarning.",
"id": "GHSA-276p-5gr8-q5fq",
"modified": "2024-11-27T21:32:43Z",
"published": "2024-11-19T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53047"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3deb12c788c385e17142ce6ec50f769852fcec65"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/494eb22f9a7bd03783e60595a57611c209175f1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb8b81ad3e893a6d18dcdd3754cc2ea2a42c0136"
}
],
"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-27G4-CRVM-H7GQ
Vulnerability from github – Published: 2024-07-16 12:30 – Updated: 2024-09-05 21:31In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Fix deadlock on DSI device attach error
DSI device attach to DSI host will be done with host device's lock held.
Un-registering host in "device attach" error path (ex: probe retry) will result in deadlock with below call trace and non operational DSI display.
Startup Call trace: [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [ 35.043048] mutex_lock_nested+0x7c/0xc8 [ 35.043060] device_del+0x4c/0x3e8 [ 35.043075] device_unregister+0x20/0x40 [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [ 35.043093] device_for_each_child+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28/0x38 [ 35.043234] really_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] __device_attach_driver+0x98/0xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] device_initial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] deferred_probe_work_func+0xa0/0xe0 [ 35.043318] process_one_work+0x254/0x700 [ 35.043330] worker_thread+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348] ret_from_fork+0x10/0x20
Shutdown Call trace: [ 365.565417] Call trace: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] schedule+0x48/0x110 [ 365.565479] schedule_timeout+0x3b0/0x448 [ 365.565496] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] device_shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart+0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184
{
"affected": [],
"aliases": [
"CVE-2022-48826"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T12:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: Fix deadlock on DSI device attach error\n\nDSI device attach to DSI host will be done with host device\u0027s lock\nheld.\n\nUn-registering host in \"device attach\" error path (ex: probe retry)\nwill result in deadlock with below call trace and non operational\nDSI display.\n\nStartup Call trace:\n[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8\n[ 35.043048] mutex_lock_nested+0x7c/0xc8\n[ 35.043060] device_del+0x4c/0x3e8\n[ 35.043075] device_unregister+0x20/0x40\n[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28\n[ 35.043093] device_for_each_child+0x68/0xb0\n[ 35.043105] mipi_dsi_host_unregister+0x40/0x90\n[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]\n[ 35.043199] mipi_dsi_attach+0x30/0x48\n[ 35.043209] tc358762_probe+0x128/0x164 [tc358762]\n[ 35.043225] mipi_dsi_drv_probe+0x28/0x38\n[ 35.043234] really_probe+0xc0/0x318\n[ 35.043244] __driver_probe_device+0x80/0xe8\n[ 35.043254] driver_probe_device+0xb8/0x118\n[ 35.043263] __device_attach_driver+0x98/0xe8\n[ 35.043273] bus_for_each_drv+0x84/0xd8\n[ 35.043281] __device_attach+0xf0/0x150\n[ 35.043290] device_initial_probe+0x1c/0x28\n[ 35.043300] bus_probe_device+0xa4/0xb0\n[ 35.043308] deferred_probe_work_func+0xa0/0xe0\n[ 35.043318] process_one_work+0x254/0x700\n[ 35.043330] worker_thread+0x4c/0x448\n[ 35.043339] kthread+0x19c/0x1a8\n[ 35.043348] ret_from_fork+0x10/0x20\n\nShutdown Call trace:\n[ 365.565417] Call trace:\n[ 365.565423] __switch_to+0x148/0x200\n[ 365.565452] __schedule+0x340/0x9c8\n[ 365.565467] schedule+0x48/0x110\n[ 365.565479] schedule_timeout+0x3b0/0x448\n[ 365.565496] wait_for_completion+0xac/0x138\n[ 365.565509] __flush_work+0x218/0x4e0\n[ 365.565523] flush_work+0x1c/0x28\n[ 365.565536] wait_for_device_probe+0x68/0x158\n[ 365.565550] device_shutdown+0x24/0x348\n[ 365.565561] kernel_restart_prepare+0x40/0x50\n[ 365.565578] kernel_restart+0x20/0x70\n[ 365.565591] __do_sys_reboot+0x10c/0x220\n[ 365.565605] __arm64_sys_reboot+0x2c/0x38\n[ 365.565619] invoke_syscall+0x4c/0x110\n[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120\n[ 365.565648] do_el0_svc+0x2c/0x90\n[ 365.565661] el0_svc+0x4c/0xf0\n[ 365.565671] el0t_64_sync_handler+0x90/0xb8\n[ 365.565682] el0t_64_sync+0x180/0x184",
"id": "GHSA-27g4-crvm-h7gq",
"modified": "2024-09-05T21:31:33Z",
"published": "2024-07-16T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48826"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a3d12ab5097b1d045e693412e6b366b7e82031b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/770d1ba9a8201ce9bee0946eb03746449b6f3b80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dddd832f35096fbc5004e3a7e58fb4d2cefb8deb"
}
],
"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-283V-8HG2-53QV
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()
There is a deadlock in ieee80211_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
{
"affected": [],
"aliases": [
"CVE-2022-49305"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()\n\nThere is a deadlock in ieee80211_beacons_stop(), which is shown below:\n\n (Thread 1) | (Thread 2)\n | ieee80211_send_beacon()\nieee80211_beacons_stop() | mod_timer()\n spin_lock_irqsave() //(1) | (wait a time)\n ... | ieee80211_send_beacon_cb()\n del_timer_sync() | spin_lock_irqsave() //(2)\n (wait timer to stop) | ...\n\nWe hold ieee-\u003ebeacon_lock in position (1) of thread 1 and use\ndel_timer_sync() to wait timer to stop, but timer handler\nalso need ieee-\u003ebeacon_lock in position (2) of thread 2.\nAs a result, ieee80211_beacons_stop() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irqsave(), which could let timer handler to obtain\nthe needed lock.",
"id": "GHSA-283v-8hg2-53qv",
"modified": "2025-04-14T21:32:21Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49305"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/042915c1bfedd684c1d98a841794ee203200571a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3"
}
],
"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-28H2-465H-Q5V7
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-01-16 18:30In the Linux kernel, the following vulnerability has been resolved:
block: Fix potential deadlock while freezing queue and acquiring sysfs_lock
For storing a value to a queue attribute, the queue_attr_store function first freezes the queue (->q_usage_counter(io)) and then acquire ->sysfs_lock. This seems not correct as the usual ordering should be to acquire ->sysfs_lock before freezing the queue. This incorrect ordering causes the following lockdep splat which we are able to reproduce always simply by accessing /sys/kernel/debug file using ls command:
[ 57.597146] WARNING: possible circular locking dependency detected [ 57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: G W [ 57.597162] ------------------------------------------------------ [ 57.597168] ls/4605 is trying to acquire lock: [ 57.597176] c00000003eb56710 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0 [ 57.597200] but task is already holding lock: [ 57.597207] c0000018e27c6810 (&sb->s_type->i_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4 [ 57.597226] which lock already depends on the new lock.
[ 57.597233] the existing dependency chain (in reverse order) is: [ 57.597241] -> #5 (&sb->s_type->i_mutex_key#3){++++}-{4:4}: [ 57.597255] down_write+0x6c/0x18c [ 57.597264] start_creating+0xb4/0x24c [ 57.597274] debugfs_create_dir+0x2c/0x1e8 [ 57.597283] blk_register_queue+0xec/0x294 [ 57.597292] add_disk_fwnode+0x2e4/0x548 [ 57.597302] brd_alloc+0x2c8/0x338 [ 57.597309] brd_init+0x100/0x178 [ 57.597317] do_one_initcall+0x88/0x3e4 [ 57.597326] kernel_init_freeable+0x3cc/0x6e0 [ 57.597334] kernel_init+0x34/0x1cc [ 57.597342] ret_from_kernel_user_thread+0x14/0x1c [ 57.597350] -> #4 (&q->debugfs_mutex){+.+.}-{4:4}: [ 57.597362] __mutex_lock+0xfc/0x12a0 [ 57.597370] blk_register_queue+0xd4/0x294 [ 57.597379] add_disk_fwnode+0x2e4/0x548 [ 57.597388] brd_alloc+0x2c8/0x338 [ 57.597395] brd_init+0x100/0x178 [ 57.597402] do_one_initcall+0x88/0x3e4 [ 57.597410] kernel_init_freeable+0x3cc/0x6e0 [ 57.597418] kernel_init+0x34/0x1cc [ 57.597426] ret_from_kernel_user_thread+0x14/0x1c [ 57.597434] -> #3 (&q->sysfs_lock){+.+.}-{4:4}: [ 57.597446] __mutex_lock+0xfc/0x12a0 [ 57.597454] queue_attr_store+0x9c/0x110 [ 57.597462] sysfs_kf_write+0x70/0xb0 [ 57.597471] kernfs_fop_write_iter+0x1b0/0x2ac [ 57.597480] vfs_write+0x3dc/0x6e8 [ 57.597488] ksys_write+0x84/0x140 [ 57.597495] system_call_exception+0x130/0x360 [ 57.597504] system_call_common+0x160/0x2c4 [ 57.597516] -> #2 (&q->q_usage_counter(io)#21){++++}-{0:0}: [ 57.597530] __submit_bio+0x5ec/0x828 [ 57.597538] submit_bio_noacct_nocheck+0x1e4/0x4f0 [ 57.597547] iomap_readahead+0x2a0/0x448 [ 57.597556] xfs_vm_readahead+0x28/0x3c [ 57.597564] read_pages+0x88/0x41c [ 57.597571] page_cache_ra_unbounded+0x1ac/0x2d8 [ 57.597580] filemap_get_pages+0x188/0x984 [ 57.597588] filemap_read+0x13c/0x4bc [ 57.597596] xfs_file_buffered_read+0x88/0x17c [ 57.597605] xfs_file_read_iter+0xac/0x158 [ 57.597614] vfs_read+0x2d4/0x3b4 [ 57.597622] ksys_read+0x84/0x144 [ 57.597629] system_call_exception+0x130/0x360 [ 57.597637] system_call_common+0x160/0x2c4 [ 57.597647] -> #1 (mapping.invalidate_lock#2){++++}-{4:4}: [ 57.597661] down_read+0x6c/0x220 [ 57.597669] filemap_fault+0x870/0x100c [ 57.597677] xfs_filemap_fault+0xc4/0x18c [ 57.597684] __do_fault+0x64/0x164 [ 57.597693] __handle_mm_fault+0x1274/0x1dac [ 57.597702] handle_mm_fault+0x248/0x48 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-53689"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix potential deadlock while freezing queue and acquiring sysfs_lock\n\nFor storing a value to a queue attribute, the queue_attr_store function\nfirst freezes the queue (-\u003eq_usage_counter(io)) and then acquire\n-\u003esysfs_lock. This seems not correct as the usual ordering should be to\nacquire -\u003esysfs_lock before freezing the queue. This incorrect ordering\ncauses the following lockdep splat which we are able to reproduce always\nsimply by accessing /sys/kernel/debug file using ls command:\n\n[ 57.597146] WARNING: possible circular locking dependency detected\n[ 57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: G W\n[ 57.597162] ------------------------------------------------------\n[ 57.597168] ls/4605 is trying to acquire lock:\n[ 57.597176] c00000003eb56710 (\u0026mm-\u003emmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0\n[ 57.597200]\n but task is already holding lock:\n[ 57.597207] c0000018e27c6810 (\u0026sb-\u003es_type-\u003ei_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4\n[ 57.597226]\n which lock already depends on the new lock.\n\n[ 57.597233]\n the existing dependency chain (in reverse order) is:\n[ 57.597241]\n -\u003e #5 (\u0026sb-\u003es_type-\u003ei_mutex_key#3){++++}-{4:4}:\n[ 57.597255] down_write+0x6c/0x18c\n[ 57.597264] start_creating+0xb4/0x24c\n[ 57.597274] debugfs_create_dir+0x2c/0x1e8\n[ 57.597283] blk_register_queue+0xec/0x294\n[ 57.597292] add_disk_fwnode+0x2e4/0x548\n[ 57.597302] brd_alloc+0x2c8/0x338\n[ 57.597309] brd_init+0x100/0x178\n[ 57.597317] do_one_initcall+0x88/0x3e4\n[ 57.597326] kernel_init_freeable+0x3cc/0x6e0\n[ 57.597334] kernel_init+0x34/0x1cc\n[ 57.597342] ret_from_kernel_user_thread+0x14/0x1c\n[ 57.597350]\n -\u003e #4 (\u0026q-\u003edebugfs_mutex){+.+.}-{4:4}:\n[ 57.597362] __mutex_lock+0xfc/0x12a0\n[ 57.597370] blk_register_queue+0xd4/0x294\n[ 57.597379] add_disk_fwnode+0x2e4/0x548\n[ 57.597388] brd_alloc+0x2c8/0x338\n[ 57.597395] brd_init+0x100/0x178\n[ 57.597402] do_one_initcall+0x88/0x3e4\n[ 57.597410] kernel_init_freeable+0x3cc/0x6e0\n[ 57.597418] kernel_init+0x34/0x1cc\n[ 57.597426] ret_from_kernel_user_thread+0x14/0x1c\n[ 57.597434]\n -\u003e #3 (\u0026q-\u003esysfs_lock){+.+.}-{4:4}:\n[ 57.597446] __mutex_lock+0xfc/0x12a0\n[ 57.597454] queue_attr_store+0x9c/0x110\n[ 57.597462] sysfs_kf_write+0x70/0xb0\n[ 57.597471] kernfs_fop_write_iter+0x1b0/0x2ac\n[ 57.597480] vfs_write+0x3dc/0x6e8\n[ 57.597488] ksys_write+0x84/0x140\n[ 57.597495] system_call_exception+0x130/0x360\n[ 57.597504] system_call_common+0x160/0x2c4\n[ 57.597516]\n -\u003e #2 (\u0026q-\u003eq_usage_counter(io)#21){++++}-{0:0}:\n[ 57.597530] __submit_bio+0x5ec/0x828\n[ 57.597538] submit_bio_noacct_nocheck+0x1e4/0x4f0\n[ 57.597547] iomap_readahead+0x2a0/0x448\n[ 57.597556] xfs_vm_readahead+0x28/0x3c\n[ 57.597564] read_pages+0x88/0x41c\n[ 57.597571] page_cache_ra_unbounded+0x1ac/0x2d8\n[ 57.597580] filemap_get_pages+0x188/0x984\n[ 57.597588] filemap_read+0x13c/0x4bc\n[ 57.597596] xfs_file_buffered_read+0x88/0x17c\n[ 57.597605] xfs_file_read_iter+0xac/0x158\n[ 57.597614] vfs_read+0x2d4/0x3b4\n[ 57.597622] ksys_read+0x84/0x144\n[ 57.597629] system_call_exception+0x130/0x360\n[ 57.597637] system_call_common+0x160/0x2c4\n[ 57.597647]\n -\u003e #1 (mapping.invalidate_lock#2){++++}-{4:4}:\n[ 57.597661] down_read+0x6c/0x220\n[ 57.597669] filemap_fault+0x870/0x100c\n[ 57.597677] xfs_filemap_fault+0xc4/0x18c\n[ 57.597684] __do_fault+0x64/0x164\n[ 57.597693] __handle_mm_fault+0x1274/0x1dac\n[ 57.597702] handle_mm_fault+0x248/0x48\n---truncated---",
"id": "GHSA-28h2-465h-q5v7",
"modified": "2025-01-16T18:30:59Z",
"published": "2025-01-11T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be26ba96421ab0a8fa2055ccf7db7832a13c44d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1a494df8350da2e673618627cb392a8669825dd"
}
],
"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-2976-MG74-V97H
Vulnerability from github – Published: 2023-10-11 15:30 – Updated: 2024-04-04 08:34Vulnerability of mutual exclusion management in the kernel module.Successful exploitation of this vulnerability will affect availability.
{
"affected": [],
"aliases": [
"CVE-2023-44119"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-11T13:15:10Z",
"severity": "HIGH"
},
"details": "Vulnerability of mutual exclusion management in the kernel module.Successful exploitation of this vulnerability will affect availability.",
"id": "GHSA-2976-mg74-v97h",
"modified": "2024-04-04T08:34:01Z",
"published": "2023-10-11T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44119"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/10"
},
{
"type": "WEB",
"url": "https://https://device.harmonyos.com/en/docs/security/update/security-bulletins-202310-0000001663676540"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-29PQ-GR25-8674
Vulnerability from github – Published: 2024-05-19 12:30 – Updated: 2024-11-06 18:31In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).
{
"affected": [],
"aliases": [
"CVE-2023-52699"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-19T11:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsysv: don\u0027t call sb_bread() with pointers_lock held\n\nsyzbot is reporting sleep in atomic context in SysV filesystem [1], for\nsb_bread() is called with rw_spinlock held.\n\nA \"write_lock(\u0026pointers_lock) =\u003e read_lock(\u0026pointers_lock) deadlock\" bug\nand a \"sb_bread() with write_lock(\u0026pointers_lock)\" bug were introduced by\n\"Replace BKL for chain locking with sysvfs-private rwlock\" in Linux 2.5.12.\n\nThen, \"[PATCH] err1-40: sysvfs locking fix\" in Linux 2.6.8 fixed the\nformer bug by moving pointers_lock lock to the callers, but instead\nintroduced a \"sb_bread() with read_lock(\u0026pointers_lock)\" bug (which made\nthis problem easier to hit).\n\nAl Viro suggested that why not to do like get_branch()/get_block()/\nfind_shared() in Minix filesystem does. And doing like that is almost a\nrevert of \"[PATCH] err1-40: sysvfs locking fix\" except that get_branch()\n from with find_shared() is called without write_lock(\u0026pointers_lock).",
"id": "GHSA-29pq-gr25-8674",
"modified": "2024-11-06T18:31:04Z",
"published": "2024-05-19T12:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52699"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"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:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-29R5-5RHX-9H26
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Reinstate disabling of BHs around IRQ handler
If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device.
If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below.
If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well.
Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed.
__schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28
{
"affected": [],
"aliases": [
"CVE-2026-46031"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:22Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ks8851: Reinstate disabling of BHs around IRQ handler\n\nIf the driver executes ks8851_irq() AND a TX packet has been sent, then\nthe driver enables TX queue via netif_wake_queue() which schedules TX\nsoftirq to queue packets for this device.\n\nIf CONFIG_PREEMPT_RT=y is set AND a packet has also been received by\nthe MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to\nallocate SKBs for the received packets. If netdev_alloc_skb_ip_align()\nis called with BH enabled, then local_bh_enable() at the end of\nnetdev_alloc_skb_ip_align() will trigger the pending softirq processing,\nwhich may ultimately call the .xmit callback ks8851_start_xmit_par().\nThe ks8851_start_xmit_par() will try to lock struct ks8851_net_par\n.lock spinlock, which is already locked by ks8851_irq() from which\nks8851_start_xmit_par() was called. This leads to a deadlock, which\nis reported by the kernel, including a trace listed below.\n\nIf CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0\n(\"net: ks8851: Fix deadlock with the SPI chip variant\") the deadlock\ncan also be triggered without received packet in the RX FIFO. The\npending softirqs will be processed on return from\nspin_unlock_bh(\u0026ks-\u003estatelock) in ks8851_irq(), which triggers the\ndeadlock as well.\n\nFix the problem by disabling BH around critical sections, including the\nIRQ handler, thus preventing the net_tx_action() softirq from triggering\nduring these critical sections. The net_tx_action() softirq is triggered\nonce BH are re-enabled and at the end of the IRQ handler, once all the\nother IRQ handler actions have been completed.\n\n __schedule from schedule_rtlock+0x1c/0x34\n schedule_rtlock from rtlock_slowlock_locked+0x548/0x904\n rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c\n rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8\n ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44\n netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188\n dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c\n sch_direct_xmit from __qdisc_run+0x1f8/0x4ec\n __qdisc_run from qdisc_run+0x1c/0x28\n qdisc_run from net_tx_action+0x1f0/0x268\n net_tx_action from handle_softirqs+0x1a4/0x270\n handle_softirqs from __local_bh_enable_ip+0xcc/0xe0\n __local_bh_enable_ip from __alloc_skb+0xd8/0x128\n __alloc_skb from __netdev_alloc_skb+0x3c/0x19c\n __netdev_alloc_skb from ks8851_irq+0x388/0x4d4\n ks8851_irq from irq_thread_fn+0x24/0x64\n irq_thread_fn from irq_thread+0x178/0x28c\n irq_thread from kthread+0x12c/0x138\n kthread from ret_from_fork+0x14/0x28",
"id": "GHSA-29r5-5rhx-9h26",
"modified": "2026-06-01T18:31:34Z",
"published": "2026-05-27T15:33:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46031"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1962027a6d223f90df8b372929f9d1a8d321ad6a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21f1707a8e978558dcb11b053855521e32ac0eec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/518040324067d8efaa2da1992297b7e7bf5640f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c9fcac3c872224316714d0d8914d9af16c76a6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/640a7631d31db87d5fa1b34cea44a99b6e78854b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be8aad558b4675f45b43080f81a9ffdeddea73a5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2CM8-23HQ-X283
Vulnerability from github – Published: 2025-05-09 09:33 – Updated: 2025-11-17 15:30In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix deadlock in ivpu_ms_cleanup()
Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume after file_priv->ms_lock is acquired.
During a failure in runtime resume, a cold boot is executed, which calls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup() that acquires file_priv->ms_lock and causes the deadlock.
{
"affected": [],
"aliases": [
"CVE-2025-37847"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T07:16:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix deadlock in ivpu_ms_cleanup()\n\nFix deadlock in ivpu_ms_cleanup() by preventing runtime resume after\nfile_priv-\u003ems_lock is acquired.\n\nDuring a failure in runtime resume, a cold boot is executed, which\ncalls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup()\nthat acquires file_priv-\u003ems_lock and causes the deadlock.",
"id": "GHSA-2cm8-23hq-x283",
"modified": "2025-11-17T15:30:30Z",
"published": "2025-05-09T09:33:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37847"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/019634f27a16796eab749e8107dae32099945f29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d12a7d43c7bab9097ba466581d8db702e7908dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a6f56762d23a1f3af15e67901493c927caaf882"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f996ecc789b5dbaaf38b6ec0a1917821789cbd9c"
}
],
"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.