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.
754 vulnerabilities reference this CWE, most recent first.
GHSA-6MVR-5CH7-JJJQ
Vulnerability from github – Published: 2026-02-14 15:32 – Updated: 2026-03-17 21:31In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix dead lock while flushing management frames
Commit [1] converted the management transmission work item into a wiphy work. Since a wiphy work can only run under wiphy lock protection, a race condition happens in below scenario:
- a management frame is queued for transmission.
- ath12k_mac_op_flush() gets called to flush pending frames associated with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush() the process waits for the transmission done.
- Since wiphy lock has been taken by the flush process, the transmission work item has no chance to run, hence the dead lock.
From user view, this dead lock results in below issue:
wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticated wlp8s0: associate with xxxxxx (try 1/3) wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING) ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1
The dead lock can be avoided by invoking wiphy_work_flush() to proactively run the queued work item. Note actually it is already present in ath12k_mac_op_flush(), however it does not protect the case where vif being NULL. Hence move it ahead to cover this case as well.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
{
"affected": [],
"aliases": [
"CVE-2026-23130"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T15:16:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix dead lock while flushing management frames\n\nCommit [1] converted the management transmission work item into a\nwiphy work. Since a wiphy work can only run under wiphy lock\nprotection, a race condition happens in below scenario:\n\n1. a management frame is queued for transmission.\n2. ath12k_mac_op_flush() gets called to flush pending frames associated\n with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()\n the process waits for the transmission done.\n3. Since wiphy lock has been taken by the flush process, the transmission\n work item has no chance to run, hence the dead lock.\n\n\u003eFrom user view, this dead lock results in below issue:\n\n wlp8s0: authenticate with xxxxxx (local address=xxxxxx)\n wlp8s0: send auth to xxxxxx (try 1/3)\n wlp8s0: authenticate with xxxxxx (local address=xxxxxx)\n wlp8s0: send auth to xxxxxx (try 1/3)\n wlp8s0: authenticated\n wlp8s0: associate with xxxxxx (try 1/3)\n wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)\n ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1\n\nThe dead lock can be avoided by invoking wiphy_work_flush() to proactively\nrun the queued work item. Note actually it is already present in\nath12k_mac_op_flush(), however it does not protect the case where vif\nbeing NULL. Hence move it ahead to cover this case as well.\n\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3",
"id": "GHSA-6mvr-5ch7-jjjq",
"modified": "2026-03-17T21:31:41Z",
"published": "2026-02-14T15:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23130"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06ac2aa13f701a0296e92f5f54ae24224d426b28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f88e9fc30a261d63946ddc6cc6a33405e6aa27c3"
}
],
"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-6P36-94F3-3RFP
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-07 00:30In the Linux kernel, the following vulnerability has been resolved:
9p: trans_fd/p9_conn_cancel: drop client lock earlier
syzbot reported a double-lock here and we no longer need this lock after requests have been moved off to local list: just drop the lock earlier.
{
"affected": [],
"aliases": [
"CVE-2022-49768"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T15:15:59Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p: trans_fd/p9_conn_cancel: drop client lock earlier\n\nsyzbot reported a double-lock here and we no longer need this\nlock after requests have been moved off to local list:\njust drop the lock earlier.",
"id": "GHSA-6p36-94f3-3rfp",
"modified": "2025-11-07T00:30:26Z",
"published": "2025-05-01T15:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49768"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52f1c45dde9136f964d63a77d19826c8a74e2c7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/612c977f5d481f551d03d83d0aef588845c1300c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/82825dbf393f7c7979d462f9609a15bde8092b3f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96760723aae1b45f733f702abb4333137143909f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4f1a01b2e81378fce9ca528d4d8a049e4b58fcd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e3031280fe4eaf61a09e60823331f81f321be8e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f14858bc77c567e089965962877ee726ffad0556"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fec1406f5e7ab20b71f6d231792b0040e3300aaf"
}
],
"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-6PWP-XWGP-J72Q
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-03 21:31In the Linux kernel, the following vulnerability has been resolved:
gpio: eic-sprd: use raw_spinlock_t in the irq startup path
sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually reviewed against the current tree.
The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep
BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv]
Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.
{
"affected": [],
"aliases": [
"CVE-2026-64429"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: eic-sprd: use raw_spinlock_t in the irq startup path\n\nsprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller\nstate through sprd_eic_update(), which takes sprd_eic-\u003elock with\nspin_lock_irqsave(). The callback can be reached from irq_startup()\nwhile setting up a requested IRQ. That path is not sleepable, but on\nPREEMPT_RT a regular spinlock_t becomes a sleeping lock.\n\nThis issue was found by our static analysis tool and then manually\nreviewed against the current tree.\n\nThe grounded PoC kept the request_threaded_irq() -\u003e __setup_irq() -\u003e\nirq_startup() -\u003e sprd_eic_irq_unmask() -\u003e sprd_eic_update() carrier and\nused the original spin_lock_irqsave(\u0026sprd_eic-\u003elock) edge. Lockdep\n\n BUG: sleeping function called from invalid context\n hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]\n sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]\n sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv]\n sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv]\n __setup_irq.constprop.0+0xd/0x30 [vuln_msv]\n\nConvert the Spreadtrum EIC controller lock to raw_spinlock_t. The\nlocked section only serializes MMIO register updates and does not contain\nsleepable operations, so keeping it non-sleeping is appropriate for the\nirqchip callbacks.",
"id": "GHSA-6pwp-xwgp-j72q",
"modified": "2026-09-03T21:31:14Z",
"published": "2026-07-25T12:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64429"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/19d63fd528719ce7d06d9aeb88d25b7d6478198a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4750909a40da9016185e0ac991510a278cecb1e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/581ac2ad001ff1128931191f249a7f2074672b7a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c3c9ec1172a4c3384b8b800b3a8896cc2c1b20e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6112fba4150039ccd90e29f2d1b788c73ad7b3dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90f0109019e6817eb40a486671b7722d1544ae29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96612bf2712cd961dbd9b52f3a9b4ab668f57628"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e244cd8b51001ba480f274c44dba9002813a4739"
}
],
"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-6R3F-6QJ7-7P6V
Vulnerability from github – Published: 2025-07-09 12:31 – Updated: 2025-11-20 21:30In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when reconnecting channels
Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening
====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W
cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200
but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30
other info that might help us debug this:
Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock);
*** DEADLOCK ***
3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200
{
"affected": [],
"aliases": [
"CVE-2025-38244"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-09T11:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential deadlock when reconnecting channels\n\nFix cifs_signal_cifsd_for_reconnect() to take the correct lock order\nand prevent the following deadlock from happening\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.16.0-rc3-build2+ #1301 Tainted: G S W\n------------------------------------------------------\ncifsd/6055 is trying to acquire lock:\nffff88810ad56038 (\u0026tcp_ses-\u003esrv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200\n\nbut task is already holding lock:\nffff888119c64330 (\u0026ret_buf-\u003echan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #2 (\u0026ret_buf-\u003echan_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_setup_session+0x81/0x4b0\n cifs_get_smb_ses+0x771/0x900\n cifs_mount_get_session+0x7e/0x170\n cifs_mount+0x92/0x2d0\n cifs_smb3_do_mount+0x161/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u003e #1 (\u0026ret_buf-\u003eses_lock){+.+.}-{3:3}:\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_match_super+0x101/0x320\n sget+0xab/0x270\n cifs_smb3_do_mount+0x1e0/0x460\n smb3_get_tree+0x55/0x90\n vfs_get_tree+0x46/0x180\n do_new_mount+0x1b0/0x2e0\n path_mount+0x6ee/0x740\n do_mount+0x98/0xe0\n __do_sys_mount+0x148/0x180\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u003e #0 (\u0026tcp_ses-\u003esrv_lock){+.+.}-{3:3}:\n check_noncircular+0x95/0xc0\n check_prev_add+0x115/0x2f0\n validate_chain+0x1cf/0x270\n __lock_acquire+0x60e/0x780\n lock_acquire.part.0+0xb4/0x1f0\n _raw_spin_lock+0x2f/0x40\n cifs_signal_cifsd_for_reconnect+0x134/0x200\n __cifs_reconnect+0x8f/0x500\n cifs_handle_standard+0x112/0x280\n cifs_demultiplex_thread+0x64d/0xbc0\n kthread+0x2f7/0x310\n ret_from_fork+0x2a/0x230\n ret_from_fork_asm+0x1a/0x30\n\nother info that might help us debug this:\n\nChain exists of:\n \u0026tcp_ses-\u003esrv_lock --\u003e \u0026ret_buf-\u003eses_lock --\u003e \u0026ret_buf-\u003echan_lock\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026ret_buf-\u003echan_lock);\n lock(\u0026ret_buf-\u003eses_lock);\n lock(\u0026ret_buf-\u003echan_lock);\n lock(\u0026tcp_ses-\u003esrv_lock);\n\n *** DEADLOCK ***\n\n3 locks held by cifsd/6055:\n #0: ffffffff857de398 (\u0026cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200\n #1: ffff888119c64060 (\u0026ret_buf-\u003eses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200\n #2: ffff888119c64330 (\u0026ret_buf-\u003echan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200",
"id": "GHSA-6r3f-6qj7-7p6v",
"modified": "2025-11-20T21:30:30Z",
"published": "2025-07-09T12:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38244"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/711741f94ac3cf9f4e3aa73aa171e76d188c0819"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f3ead8ebc0ef65b6c89a13912b4e80218425629"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c82c7041258d96e3286f6790ab700e4edd3cc9e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe035dc78aa6ca8f862857d45beaf7a0e03206ca"
}
],
"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-6R4H-5JP9-8J35
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: tty: serial: Fix deadlock in sa1100_set_termios()
There is a deadlock in sa1100_set_termios(), which is shown below:
(Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ...
We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever.
This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49304"
],
"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: tty: serial: Fix deadlock in sa1100_set_termios()\n\nThere is a deadlock in sa1100_set_termios(), which is shown\nbelow:\n\n (Thread 1) | (Thread 2)\n | sa1100_enable_ms()\nsa1100_set_termios() | mod_timer()\n spin_lock_irqsave() //(1) | (wait a time)\n ... | sa1100_timeout()\n del_timer_sync() | spin_lock_irqsave() //(2)\n (wait timer to stop) | ...\n\nWe hold sport-\u003eport.lock in position (1) of thread 1 and\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need sport-\u003eport.lock in position (2) of thread 2. As a result,\nsa1100_set_termios() will block forever.\n\nThis patch moves del_timer_sync() before spin_lock_irqsave()\nin order to prevent the deadlock.",
"id": "GHSA-6r4h-5jp9-8j35",
"modified": "2025-04-14T21:32:21Z",
"published": "2025-04-14T21:32:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49304"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0976808d0d171ec837d4bd3e9f4ad4a00ab703b8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09a5958a2452ad22d0cb638711ef34ea1863a829"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34d91e555e5582cffdbcbb75517bc9217866823e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/553213432ef0c295becdc08c0207d2094468f673"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62b2caef400c1738b6d22f636c628d9f85cd4c4c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e2273eefab54a521d9c59efb6e1114e742bdf41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85e20f8bd31a46d8c60103d0274a8ebe8f47f2b2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/920f0ae7a129ffee98a106e3bbdfd61a2a59e939"
}
],
"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-6R8R-3CX2-3H8F
Vulnerability from github – Published: 2025-03-11 00:31 – Updated: 2025-03-11 00:31In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()
In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard lockup call trace hangs the system.
Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40 Kernel panic - not syncing: Hard LOCKUP
The same CPU tries to claim the phba->port_list_lock twice.
Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need to take the phba->port_list_lock within lpfc_dmp_dbg().
{
"affected": [],
"aliases": [
"CVE-2022-49542"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()\n\nIn an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard\nlockup call trace hangs the system.\n\nCall Trace:\n _raw_spin_lock_irqsave+0x32/0x40\n lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc]\n lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc]\n lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc]\n lpfc_els_flush_cmd+0x43c/0x670 [lpfc]\n lpfc_els_flush_all_cmd+0x37/0x60 [lpfc]\n lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc]\n lpfc_do_work+0x1485/0x1d70 [lpfc]\n kthread+0x112/0x130\n ret_from_fork+0x1f/0x40\nKernel panic - not syncing: Hard LOCKUP\n\nThe same CPU tries to claim the phba-\u003eport_list_lock twice.\n\nMove the cfg_log_verbose checks as part of the lpfc_printf_vlog() and\nlpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need\nto take the phba-\u003eport_list_lock within lpfc_dmp_dbg().",
"id": "GHSA-6r8r-3cx2-3h8f",
"modified": "2025-03-11T00:31:48Z",
"published": "2025-03-11T00:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49542"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09c772557a4fd9490fed1bfb133268313ea22213"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/271725e4028559ae7974d762a8467dc9de412f2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc6501afccec55b8b6c90584cbf71f1fefa77d1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e294647b1aed4247fe52851f3a3b2b19ae906228"
}
],
"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-6RH8-WW5V-VX2C
Vulnerability from github – Published: 2024-09-27 15:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
rtmutex: Drop rt_mutex::wait_lock before scheduling
rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning.
Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop.
[ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ]
{
"affected": [],
"aliases": [
"CVE-2024-46829"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-27T13:15:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtmutex: Drop rt_mutex::wait_lock before scheduling\n\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0027scheduling in atomic\u0027 warning.\n\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\n\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n \tmassaged changelog, added Fixes tag ]",
"id": "GHSA-6rh8-ww5v-vx2c",
"modified": "2025-11-04T00:31:30Z",
"published": "2024-09-27T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46829"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1401da1486dc1cdbef6025fd74a3977df3a3e5d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/432efdbe7da5ecfcbc0c2180cfdbab1441752a38"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a976e9a47e8e5b326de671811561cab12e6fb1f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85f03ca98e07cd0786738b56ae73740bce0ac27f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93f44655472d9cd418293d328f9d141ca234ad83"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a92d81c9efec9280681c27a2c0a963fd0f1338e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d33d26036a0274b472299d7dcdaa5fb34329f91b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f13b5afc5c4889569d84c3011ce449f61fccfb28"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"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-6RHP-8RX2-2869
Vulnerability from github – Published: 2024-10-21 21:30 – Updated: 2026-05-12 12:32In the Linux kernel, the following vulnerability has been resolved:
ext4: fix i_data_sem unlock order in ext4_ind_migrate()
Fuzzing reports a possible deadlock in jbd2_log_wait_commit.
This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call.
This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously.
Found by Linux Verification Center (linuxtesting.org) with syzkaller.
Rule: add
{
"affected": [],
"aliases": [
"CVE-2024-50006"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T19:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix i_data_sem unlock order in ext4_ind_migrate()\n\nFuzzing reports a possible deadlock in jbd2_log_wait_commit.\n\nThis issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require\nsynchronous updates because the file descriptor is opened with O_SYNC.\nThis can lead to the jbd2_journal_stop() function calling\njbd2_might_wait_for_commit(), potentially causing a deadlock if the\nEXT4_IOC_MIGRATE call races with a write(2) system call.\n\nThis problem only arises when CONFIG_PROVE_LOCKING is enabled. In this\ncase, the jbd2_might_wait_for_commit macro locks jbd2_handle in the\njbd2_journal_stop function while i_data_sem is locked. This triggers\nlockdep because the jbd2_journal_start function might also lock the same\njbd2_handle simultaneously.\n\nFound by Linux Verification Center (linuxtesting.org) with syzkaller.\n\nRule: add",
"id": "GHSA-6rhp-8rx2-2869",
"modified": "2026-05-12T12:32:12Z",
"published": "2024-10-21T21:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50006"
},
{
"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://cert-portal.siemens.com/productcert/html/ssa-398330.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c46d6060d3e38de22196c1fe7706c5a3c696285"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4192adefc9c570698821c5eb9873320eac2fcbf1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53b1999cfd2c7addf2e581a32865fe8835467b44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6252cb6bde7fc76cb8dcb49d1def7c326b190820"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9fedf51ab8cf7b69bff08f37fe0989fec7f5d870"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc749e61c011c255d81b192a822db650c68b313f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d43776b907659affef1de888525847d64b244194"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d58a00e981d3118b91d503da263e640b7cde6729"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef05572da0c0eb89614ed01cc17d3c882bdbd1ff"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"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-6V44-4W2G-HXP9
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35A locking inconsistency issue was discovered in the tty subsystem of the Linux kernel through 5.9.13. drivers/tty/tty_io.c and drivers/tty/tty_jobctrl.c may allow a read-after-free attack against TIOCGSID, aka CID-c8bcd9c5be24.
{
"affected": [],
"aliases": [
"CVE-2020-29660"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-09T17:15:00Z",
"severity": "HIGH"
},
"details": "A locking inconsistency issue was discovered in the tty subsystem of the Linux kernel through 5.9.13. drivers/tty/tty_io.c and drivers/tty/tty_jobctrl.c may allow a read-after-free attack against TIOCGSID, aka CID-c8bcd9c5be24.",
"id": "GHSA-6v44-4w2g-hxp9",
"modified": "2022-05-24T17:35:46Z",
"published": "2022-05-24T17:35:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29660"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00018.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00010.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BOB25SU6XUL4TNP7KB63WNZSYTIYFDPP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MZ7OAKAEFAXQRGBZK4LYUWINCD3D2XCL"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210122-0001"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4843"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/164950/Kernel-Live-Patch-Security-Notice-LSN-0082-1.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/12/10/1"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6VG3-7HP6-MQC5
Vulnerability from github – Published: 2026-07-27 09:31 – Updated: 2026-07-30 06:32In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path
In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock.
Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().
{
"affected": [],
"aliases": [
"CVE-2026-64534"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-27T08:16:22Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path\n\nIn nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected,\nnvmet_req_uninit() is called unconditionally. However, if the command\narrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init()\nhad returned false and percpu_ref_tryget_live() was never executed. The\nunconditional percpu_ref_put() inside nvmet_req_uninit() then causes a\nrefcount underflow, leading to a WARNING in\npercpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and\neventually a permanent workqueue deadlock.\n\nCheck cmd-\u003eflags \u0026 NVMET_TCP_F_INIT_FAILED before calling\nnvmet_req_uninit(), matching the existing pattern in\nnvmet_tcp_execute_request().",
"id": "GHSA-6vg3-7hp6-mqc5",
"modified": "2026-07-30T06:32:32Z",
"published": "2026-07-27T09:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64534"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22ec7a9fe9153d2737ee9b2fa6d2e43a1491decf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2ed3c9d955e8cd6361f130623baa664a75fb345f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4606467a75cfc16721937272ed29462a750b60c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba35b1c674ca3841c0dfadd698f2c1b3ec542d4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7874dad84b20433c0fe3919f291a762d40de08b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d306da8833e75f669d93424fd84940236f3850bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e602c93b25bda4a9d0ff1791a4bdbfdcbb074af1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.