CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
720 vulnerabilities reference this CWE, most recent first.
GHSA-QWCV-C594-JH3G
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2026-05-12 12:32In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from softirq context. However using only spin_lock() to get sta->ps_lock in ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation.
rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 _dosoftirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 _syssendmsg+0x1e8/0x218 _sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150
Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise on the same CPU that is holding the lock.
{
"affected": [],
"aliases": [
"CVE-2024-40912"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()\n\nThe ieee80211_sta_ps_deliver_wakeup() function takes sta-\u003eps_lock to\nsynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from\nsoftirq context. However using only spin_lock() to get sta-\u003eps_lock in\nieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute\non this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to\ntake this same lock ending in deadlock. Below is an example of rcu stall\nthat arises in such situation.\n\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996\n rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4)\n CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742\n Hardware name: RPT (r1) (DT)\n pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : queued_spin_lock_slowpath+0x58/0x2d0\n lr : invoke_tx_handlers_early+0x5b4/0x5c0\n sp : ffff00001ef64660\n x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8\n x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000\n x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000\n x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000\n x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80\n x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da\n x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440\n x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880\n x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8\n Call trace:\n queued_spin_lock_slowpath+0x58/0x2d0\n ieee80211_tx+0x80/0x12c\n ieee80211_tx_pending+0x110/0x278\n tasklet_action_common.constprop.0+0x10c/0x144\n tasklet_action+0x20/0x28\n _stext+0x11c/0x284\n ____do_softirq+0xc/0x14\n call_on_irq_stack+0x24/0x34\n do_softirq_own_stack+0x18/0x20\n do_softirq+0x74/0x7c\n __local_bh_enable_ip+0xa0/0xa4\n _ieee80211_wake_txqs+0x3b0/0x4b8\n __ieee80211_wake_queue+0x12c/0x168\n ieee80211_add_pending_skbs+0xec/0x138\n ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480\n ieee80211_mps_sta_status_update.part.0+0xd8/0x11c\n ieee80211_mps_sta_status_update+0x18/0x24\n sta_apply_parameters+0x3bc/0x4c0\n ieee80211_change_station+0x1b8/0x2dc\n nl80211_set_station+0x444/0x49c\n genl_family_rcv_msg_doit.isra.0+0xa4/0xfc\n genl_rcv_msg+0x1b0/0x244\n netlink_rcv_skb+0x38/0x10c\n genl_rcv+0x34/0x48\n netlink_unicast+0x254/0x2bc\n netlink_sendmsg+0x190/0x3b4\n ____sys_sendmsg+0x1e8/0x218\n ___sys_sendmsg+0x68/0x8c\n __sys_sendmsg+0x44/0x84\n __arm64_sys_sendmsg+0x20/0x28\n do_el0_svc+0x6c/0xe8\n el0_svc+0x14/0x48\n el0t_64_sync_handler+0xb0/0xb4\n el0t_64_sync+0x14c/0x150\n\nUsing spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise\non the same CPU that is holding the lock.",
"id": "GHSA-qwcv-c594-jh3g",
"modified": "2026-05-12T12:32:01Z",
"published": "2024-07-12T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40912"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/28ba44d680a30c51cf485a2f5a3b680e66ed3932"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44c06bbde6443de206b30f513100b5670b23fc5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/456bbb8a31e425177dc0e8d4f98728a560c20e81"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47d176755d5c0baf284eff039560f8c1ba0ea485"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c49b58b9a2bed707e7638576e54c4bccd97b9eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d90bdff79f8e40adf889b5408bfcf521528b169f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e51637e0c66a6f72d134d9f95daa47ea62b43c7e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e7e916d693dcb5a297f40312600a82475f2e63bc"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QX5P-7G35-JJ49
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-10-09 15:32In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: fix TX fifo corruption
Sometimes, when a packet is received on channel A at almost the same time as a packet is about to be transmitted on channel B, we observe with a logic analyzer that the received packet on channel A is transmitted on channel B. In other words, the Tx buffer data on channel B is corrupted with data from channel A.
The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), which changed the EFR locking to operate on each channel instead of chip-wise.
This commit has introduced a regression, because the EFR lock is used not only to protect the EFR registers access, but also, in a very obscure and undocumented way, to protect access to the data buffer, which is shared by the Tx and Rx handlers, but also by each channel of the IC.
Fix this regression first by switching to kfifo_out_linear_ptr() in sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.
Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for each channel.
{
"affected": [],
"aliases": [
"CVE-2024-44951"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: sc16is7xx: fix TX fifo corruption\n\nSometimes, when a packet is received on channel A at almost the same time\nas a packet is about to be transmitted on channel B, we observe with a\nlogic analyzer that the received packet on channel A is transmitted on\nchannel B. In other words, the Tx buffer data on channel B is corrupted\nwith data from channel A.\n\nThe problem appeared since commit 4409df5866b7 (\"serial: sc16is7xx: change\nEFR lock to operate on each channels\"), which changed the EFR locking to\noperate on each channel instead of chip-wise.\n\nThis commit has introduced a regression, because the EFR lock is used not\nonly to protect the EFR registers access, but also, in a very obscure and\nundocumented way, to protect access to the data buffer, which is shared by\nthe Tx and Rx handlers, but also by each channel of the IC.\n\nFix this regression first by switching to kfifo_out_linear_ptr() in\nsc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.\n\nSecondly, replace the chip-wise Rx buffer with a separate Rx buffer for\neach channel.",
"id": "GHSA-qx5p-7g35-jj49",
"modified": "2024-10-09T15:32:18Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44951"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09cfe05e9907f3276887a20e267cc40e202f4fdd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/133f4c00b8b2bfcacead9b81e7e8edfceb4b06c4"
}
],
"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-QXGC-W63M-XVQR
Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-07-08 06:31In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG
There were multiple issues in that code.
First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock.
Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock.
Then we used down_read_trylock() instead of waiting for the reset to finish.
(cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)
{
"affected": [],
"aliases": [
"CVE-2026-53293"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T20:17:22Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG\n\nThere were multiple issues in that code.\n\nFirst of all the order between the reset semaphore and the mm_lock was\nwrong (e.g. copy_to_user) was called while holding the lock.\n\nThen we allocated memory while holding the reset semaphore which is also\na pretty big bug and can deadlock.\n\nThen we used down_read_trylock() instead of waiting for the reset to\nfinish.\n\n(cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)",
"id": "GHSA-qxgc-w63m-xvqr",
"modified": "2026-07-08T06:31:35Z",
"published": "2026-06-26T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53293"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ef196a208385b7d7da79f411c161b04e97283e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c29d20470d4566d1b68df57097d642d01f8b427"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61957c2e467b39b528a290016367d32a433fa846"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c4254c8f5836e77ae83e7fc037f02b69f7a0977"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a31c3feb54b15a90232e497ad0e27e8a82052d8d"
}
],
"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-QXMR-4P8X-2R7C
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-17 21:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: When HCI work queue is drained, only queue chained work
The HCI command, event, and data packet processing workqueue is drained to avoid deadlock in commit 76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").
There is another delayed work, which will queue command to this drained workqueue. Which results in the following error report:
Bluetooth: hci2: command 0x040f tx timeout WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140 Workqueue: events hci_cmd_timeout RIP: 0010:__queue_work+0xdad/0x1140 RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093 RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000 RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08 RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700 R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60 R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800 FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30
To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue the timeout workqueue while command workqueue is draining.
{
"affected": [],
"aliases": [
"CVE-2022-50166"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: When HCI work queue is drained, only queue chained work\n\nThe HCI command, event, and data packet processing workqueue is drained\nto avoid deadlock in commit\n76727c02c1e1 (\"Bluetooth: Call drain_workqueue() before resetting state\").\n\nThere is another delayed work, which will queue command to this drained\nworkqueue. Which results in the following error report:\n\nBluetooth: hci2: command 0x040f tx timeout\nWARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140\nWorkqueue: events hci_cmd_timeout\nRIP: 0010:__queue_work+0xdad/0x1140\nRSP: 0000:ffffc90002cffc60 EFLAGS: 00010093\nRAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000\nRDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08\nRBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700\nR10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60\nR13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800\nFS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u003cTASK\u003e\n ? queue_work_on+0xcb/0x110\n ? lockdep_hardirqs_off+0x90/0xd0\n queue_work_on+0xee/0x110\n process_one_work+0x996/0x1610\n ? pwq_dec_nr_in_flight+0x2a0/0x2a0\n ? rwlock_bug.part.0+0x90/0x90\n ? _raw_spin_lock_irq+0x41/0x50\n worker_thread+0x665/0x1080\n ? process_one_work+0x1610/0x1610\n kthread+0x2e9/0x3a0\n ? kthread_complete_and_exit+0x40/0x40\n ret_from_fork+0x1f/0x30\n \u003c/TASK\u003e\n\nTo fix this, we can add a new HCI_DRAIN_WQ flag, and don\u0027t queue the\ntimeout workqueue while command workqueue is draining.",
"id": "GHSA-qxmr-4p8x-2r7c",
"modified": "2025-11-17T21:31:18Z",
"published": "2025-06-18T12:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50166"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b382555706558f5c0587862b6dc03e96a252bba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4bf367fa1fefabdf14938d0ac9ed60020389112e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/877afadad2dce8aae1f2aad8ce47e072d4f6165e"
}
],
"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-R34W-XRJ9-CPVR
Vulnerability from github – Published: 2023-05-31 00:31 – Updated: 2024-04-04 04:24Jean-Baptiste Cayrou discovered that the shiftfs file system in the Ubuntu Linux kernel contained a race condition when handling inode locking in some situations. A local attacker could use this to cause a denial of service (kernel deadlock).
{
"affected": [],
"aliases": [
"CVE-2023-2612"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-31T00:15:10Z",
"severity": "MODERATE"
},
"details": "Jean-Baptiste Cayrou discovered that the shiftfs file system in the Ubuntu Linux kernel contained a race condition when handling inode locking in some situations. A local attacker could use this to cause a denial of service (kernel deadlock).",
"id": "GHSA-r34w-xrj9-cpvr",
"modified": "2024-04-04T04:24:52Z",
"published": "2023-05-31T00:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2612"
},
{
"type": "WEB",
"url": "https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/kinetic/commit/?id=02b47547824b1cd0d55c6744f91886f04de8947e"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/CVE-2023-2612"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/notices/USN-6122-1"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/notices/USN-6123-1"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/notices/USN-6124-1"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/notices/USN-6127-1"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R3PQ-5QQG-MWGH
Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31Multiple Cisco products are affected by a vulnerability in the Snort 3 Detection Engine that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection.
This vulnerability is due to an error in the binder module initialization logic of the Snort Detection Engine. An attacker could exploit this vulnerability by sending certain packets through an established connection that is parsed by Snort 3. A successful exploit could allow the attacker to cause a DoS condition when the Snort 3 Detection Engine restarts unexpectedly.
{
"affected": [],
"aliases": [
"CVE-2026-20065"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T18:16:21Z",
"severity": "MODERATE"
},
"details": "Multiple Cisco products are affected by a vulnerability in the Snort 3 Detection Engine that could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to restart, resulting in an interruption of packet inspection.\n\nThis vulnerability is due to an error in the binder module initialization logic of the Snort Detection Engine. An attacker could exploit this vulnerability by sending certain packets through an established connection that is parsed by Snort 3. A successful exploit could allow the attacker to cause a DoS condition when the Snort 3 Detection Engine restarts unexpectedly.",
"id": "GHSA-r3pq-5qqg-mwgh",
"modified": "2026-03-04T18:31:55Z",
"published": "2026-03-04T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20065"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort3-multi-dos-XFWkWSwz"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-R45Q-6FX6-2Q7Q
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In the Linux kernel, the following vulnerability has been resolved:
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); / when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. / if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev)
As shown above, when it is allowed to do async probes, because of out of memory or work limit, async work is not allowed, to do sync execute instead. it will lead to A-A deadlock because of __device_attach_async_helper getting lock dev.
To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49371"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix deadlock in __device_attach\n\nIn __device_attach function, The lock holding logic is as follows:\n...\n__device_attach\ndevice_lock(dev) // get lock dev\n async_schedule_dev(__device_attach_async_helper, dev); // func\n async_schedule_node\n async_schedule_node_domain(func)\n entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);\n\t/* when fail or work limit, sync to execute func, but\n\t __device_attach_async_helper will get lock dev as\n\t well, which will lead to A-A deadlock. */\n\tif (!entry || atomic_read(\u0026entry_count) \u003e MAX_WORK) {\n\t func;\n\telse\n\t queue_work_node(node, system_unbound_wq, \u0026entry-\u003ework)\n device_unlock(dev)\n\nAs shown above, when it is allowed to do async probes, because of\nout of memory or work limit, async work is not allowed, to do\nsync execute instead. it will lead to A-A deadlock because of\n__device_attach_async_helper getting lock dev.\n\nTo fix the deadlock, move the async_schedule_dev outside device_lock,\nas we can see, in async_schedule_node_domain, the parameter of\nqueue_work_node is system_unbound_wq, so it can accept concurrent\noperations. which will also not change the code logic, and will\nnot lead to deadlock.",
"id": "GHSA-r45q-6fx6-2q7q",
"modified": "2025-04-14T21:32:22Z",
"published": "2025-04-14T21:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49371"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34fdd9b7def9d2fcb71bb7b0bc4848dd7313767e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36ee9ffca8ef56c302f2855c4a5fccf61c0c1ada"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/593b595332bd2d65e1a5c1ae7897996c157f5468"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b232b02bf3c205b13a26dcec08e53baddd8e59ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d53a227bfcd5160ce1b61d9954901968a20651e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df6de52b80aa3b46f5ac804412355ffe2e1df93e"
}
],
"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-R49F-C964-6W6W
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2024-12-09 15:31In the Linux kernel, the following vulnerability has been resolved:
i2c: lpi2c: Avoid calling clk_get_rate during transfer
Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.
{
"affected": [],
"aliases": [
"CVE-2024-40965"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.",
"id": "GHSA-r49f-c964-6w6w",
"modified": "2024-12-09T15:31:32Z",
"published": "2024-07-12T15:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d038693e08adf9c162c6377800495e4f5a2df045"
}
],
"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-R5FX-27QQ-PWQG
Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-08 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop()
dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro, which expects hsotg->lock to be held since it does spin_unlock/spin_lock around the gadget driver callback invocation.
However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating() without holding the lock. This leads to: - spin_unlock on a lock that is not held (undefined behavior) - The lock remaining held after dwc2_gadget_exit_clock_gating() returns, causing a deadlock when spin_lock_irqsave() is called later in the same function.
Fix this by acquiring hsotg->lock before calling dwc2_gadget_exit_clock_gating() and releasing it afterwards, which satisfies the locking requirement of the call_gadget() macro.
{
"affected": [],
"aliases": [
"CVE-2026-31756"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-01T15:16:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop()\n\ndwc2_gadget_exit_clock_gating() internally calls call_gadget() macro,\nwhich expects hsotg-\u003elock to be held since it does spin_unlock/spin_lock\naround the gadget driver callback invocation.\n\nHowever, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating()\nwithout holding the lock. This leads to:\n - spin_unlock on a lock that is not held (undefined behavior)\n - The lock remaining held after dwc2_gadget_exit_clock_gating() returns,\n causing a deadlock when spin_lock_irqsave() is called later in the\n same function.\n\nFix this by acquiring hsotg-\u003elock before calling\ndwc2_gadget_exit_clock_gating() and releasing it afterwards, which\nsatisfies the locking requirement of the call_gadget() macro.",
"id": "GHSA-r5fx-27qq-pwqg",
"modified": "2026-05-08T18:31:25Z",
"published": "2026-05-01T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31756"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ed9d2dd9f29828c311db6ec4b8e0d34bfd6d6a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/51b62286fc668c6eb74dee7624ec0beec3c5a0ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61937f686290494998236c680ce0836b8dd63a3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ffe31acb3b77a30ae34d01719a269881569fb7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9bb4b5ed7f8c4f95cc556bdf042b0ba2fa13557a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/beab10429439e20708036a66fb0d97ffb79da6a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9fcca3e87463013d595c65c2189ffaa32ad3b50"
}
],
"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-R5HJ-8P6X-9RQ8
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: f_midi: f_midi_complete to call queue_work
When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock.
Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler.
{
"affected": [],
"aliases": [
"CVE-2025-21859"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: f_midi: f_midi_complete to call queue_work\n\nWhen using USB MIDI, a lock is attempted to be acquired twice through a\nre-entrant call to f_midi_transmit, causing a deadlock.\n\nFix it by using queue_work() to schedule the inner f_midi_transmit() via\na high priority work queue from the completion handler.",
"id": "GHSA-r5hj-8p6x-9rq8",
"modified": "2026-05-12T15:30:51Z",
"published": "2025-03-12T12:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21859"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f10923404705a94891e612dff3b75e828a78368"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/24a942610ee9bafb2692a456ae850c5b2e409b05"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ab37fcb42832cdd3e9d5e50653285ca84d6686f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/727dee0857946b85232526de4f5a957fe163e89a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8aa6b4be1f4efccbfc533e6ec8841d26e4fa8dba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b09957657d7767d164b3432af2129bd72947553c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/deeee3adb2c01eedab32c3b4519337689ad02e8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9fec6f42c45db2f62dc373fb1a10d2488c04e79"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.