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.
693 vulnerabilities reference this CWE, most recent first.
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-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-6VR7-4HPQ-76R6
Vulnerability from github – Published: 2024-02-29 06:30 – Updated: 2024-12-10 21:30In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range
When running an SVA case, the following soft lockup is triggered:
watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8
Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains.
The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } }
Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold.
{
"affected": [],
"aliases": [
"CVE-2023-52484"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T06:15:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range\n\nWhen running an SVA case, the following soft lockup is triggered:\n--------------------------------------------------------------------\nwatchdog: BUG: soft lockup - CPU#244 stuck for 26s!\npstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50\nlr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50\nsp : ffff8000d83ef290\nx29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000\nx26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000\nx23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0\nx20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0\nx14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a\nx2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001\nCall trace:\n arm_smmu_cmdq_issue_cmdlist+0x178/0xa50\n __arm_smmu_tlb_inv_range+0x118/0x254\n arm_smmu_tlb_inv_range_asid+0x6c/0x130\n arm_smmu_mm_invalidate_range+0xa0/0xa4\n __mmu_notifier_invalidate_range_end+0x88/0x120\n unmap_vmas+0x194/0x1e0\n unmap_region+0xb4/0x144\n do_mas_align_munmap+0x290/0x490\n do_mas_munmap+0xbc/0x124\n __vm_munmap+0xa8/0x19c\n __arm64_sys_munmap+0x28/0x50\n invoke_syscall+0x78/0x11c\n el0_svc_common.constprop.0+0x58/0x1c0\n do_el0_svc+0x34/0x60\n el0_svc+0x2c/0xd4\n el0t_64_sync_handler+0x114/0x140\n el0t_64_sync+0x1a4/0x1a8\n--------------------------------------------------------------------\n\nNote that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed\nto \"arm_smmu_mm_arch_invalidate_secondary_tlbs\", yet the problem remains.\n\nThe commit 06ff87bae8d3 (\"arm64: mm: remove unused functions and variable\nprotoypes\") fixed a similar lockup on the CPU MMU side. Yet, it can occur\nto SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called\ntypically next to MMU tlb flush function, e.g.\n\ttlb_flush_mmu_tlbonly {\n\t\ttlb_flush {\n\t\t\t__flush_tlb_range {\n\t\t\t\t// check MAX_TLBI_OPS\n\t\t\t}\n\t\t}\n\t\tmmu_notifier_arch_invalidate_secondary_tlbs {\n\t\t\tarm_smmu_mm_arch_invalidate_secondary_tlbs {\n\t\t\t\t// does not check MAX_TLBI_OPS\n\t\t\t}\n\t\t}\n\t}\n\nClone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an\nSVA case SMMU uses the CPU page table, so it makes sense to align with the\ntlbflush code. Then, replace per-page TLBI commands with a single per-asid\nTLBI command, if the request size hits this threshold.",
"id": "GHSA-6vr7-4hpq-76r6",
"modified": "2024-12-10T21:30:51Z",
"published": "2024-02-29T06:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52484"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264"
}
],
"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-6VRX-35FP-7WHC
Vulnerability from github – Published: 2026-04-03 18:31 – Updated: 2026-05-26 15:32In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Fix deadlock in soft reset sequence
The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disable_irq() which internally waits for IRQ handlers, i.e. itself, to complete.
Use disable_irq_nosync() during a soft reset instead.
{
"affected": [],
"aliases": [
"CVE-2026-23470"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T16:16:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: Fix deadlock in soft reset sequence\n\nThe soft reset sequence is currently executed from the threaded IRQ\nhandler, hence it cannot call disable_irq() which internally waits\nfor IRQ handlers, i.e. itself, to complete.\n\nUse disable_irq_nosync() during a soft reset instead.",
"id": "GHSA-6vrx-35fp-7whc",
"modified": "2026-05-26T15:32:07Z",
"published": "2026-04-03T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23470"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f39b48a2d3b1fe83f99477250cd0cd67ca1e1c6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9497b1f309436971726e229aa6026954ea7c28e9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a55c2a5c8d680156495b7b1e2a9f5a3e313ba524"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f99e8b813ae5ce8ffd62c33f5753bf0a008af4b1"
}
],
"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-6W26-4VM6-C7F2
Vulnerability from github – Published: 2024-11-19 18:31 – Updated: 2024-11-27 21:32In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL
Upon failure all locks need to be dropped before returning to the user.
(cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)
{
"affected": [],
"aliases": [
"CVE-2024-53086"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T18:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL\n\nUpon failure all locks need to be dropped before returning to the user.\n\n(cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)",
"id": "GHSA-6w26-4vm6-c7f2",
"modified": "2024-11-27T21:32:44Z",
"published": "2024-11-19T18:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53086"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64a2b6ed4bfd890a0e91955dd8ef8422a3944ed9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96397b1e25dda8389dea63ec914038a170bf953d"
}
],
"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.