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.
724 vulnerabilities reference this CWE, most recent first.
GHSA-53GX-3HRH-CR29
Vulnerability from github – Published: 2024-02-23 15:30 – Updated: 2024-06-25 21:31In the Linux kernel, the following vulnerability has been resolved:
serial: imx: fix tx statemachine deadlock
When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless.
imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND.
{
"affected": [],
"aliases": [
"CVE-2023-52456"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-23T15:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: imx: fix tx statemachine deadlock\n\nWhen using the serial port as RS485 port, the tx statemachine is used to\ncontrol the RTS pin to drive the RS485 transceiver TX_EN pin. When the\nTTY port is closed in the middle of a transmission (for instance during\nuserland application crash), imx_uart_shutdown disables the interface\nand disables the Transmission Complete interrupt. afer that,\nimx_uart_stop_tx bails on an incomplete transmission, to be retriggered\nby the TC interrupt. This interrupt is disabled and therefore the tx\nstatemachine never transitions out of SEND. The statemachine is in\ndeadlock now, and the TX_EN remains low, making the interface useless.\n\nimx_uart_stop_tx now checks for incomplete transmission AND whether TC\ninterrupts are enabled before bailing to be retriggered. This makes sure\nthe state machine handling is reached, and is properly set to\nWAIT_AFTER_SEND.",
"id": "GHSA-53gx-3hrh-cr29",
"modified": "2024-06-25T21:31:11Z",
"published": "2024-02-23T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52456"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00016.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-542Q-G93G-WJG9
Vulnerability from github – Published: 2025-07-30 09:31 – Updated: 2025-07-30 09:31A Zigbee Radio Co-Processor (RCP), which is using SiLabs EmberZNet Zigbee stack, was unable to send messages to the host system (CPCd) due to heavy Zigbee traffic, resulting in a Denial of Service (DoS) attack, Only hard reset will bring the device to normal operation
{
"affected": [],
"aliases": [
"CVE-2025-1221"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-30T08:15:33Z",
"severity": "MODERATE"
},
"details": "A Zigbee Radio Co-Processor (RCP), which is using SiLabs EmberZNet Zigbee stack, was unable to send messages to the host system (CPCd) due to heavy Zigbee traffic, resulting in a Denial of Service (DoS) attack, Only hard reset will bring the device to normal operation",
"id": "GHSA-542q-g93g-wjg9",
"modified": "2025-07-30T09:31:22Z",
"published": "2025-07-30T09:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1221"
},
{
"type": "WEB",
"url": "https://community.silabs.com/068Vm00000Sadyn"
},
{
"type": "WEB",
"url": "https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-7.4.4.0.pdf"
},
{
"type": "WEB",
"url": "https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-8.0.2.0.pdf"
},
{
"type": "WEB",
"url": "https://www.silabs.com/documents/public/release-notes/emberznet-release-notes-8.1.0.0.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-54VM-JHGV-PHV5
Vulnerability from github – Published: 2025-03-17 21:30 – Updated: 2025-03-17 21:30In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()
There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below:
(Thread 1) | (Thread 2) | _set_timer() rtw_joinbss_event_prehandle()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | _rtw_join_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...
We hold pmlmepriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtw_joinbss_event_prehandle() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() to spin_lock_irq() in _rtw_join_timeout_handler() in order to prevent deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49311"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()\n\nThere is a deadlock in rtw_joinbss_event_prehandle(), which is shown\nbelow:\n\n (Thread 1) | (Thread 2)\n | _set_timer()\nrtw_joinbss_event_prehandle()| mod_timer()\n spin_lock_bh() //(1) | (wait a time)\n ... | _rtw_join_timeout_handler()\n del_timer_sync() | spin_lock_bh() //(2)\n (wait timer to stop) | ...\n\nWe hold pmlmepriv-\u003elock in position (1) of thread 1 and\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need pmlmepriv-\u003elock in position (2) of thread 2.\nAs a result, rtw_joinbss_event_prehandle() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_bh(), which could let timer handler to obtain\nthe needed lock. What`s more, we change spin_lock_bh() to\nspin_lock_irq() in _rtw_join_timeout_handler() in order to\nprevent deadlock.",
"id": "GHSA-54vm-jhgv-phv5",
"modified": "2025-03-17T21:30:33Z",
"published": "2025-03-17T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49311"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/041879b12ddb0c6c83ed9c0bdd10dc82a056f2fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f6c99b94ca3caad346876b3e22e3ca3d25bc8ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae60744d5fad840b9d056d35b4b652d95e755846"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eca9748d9267a38d532464e3305a38629e9c35a9"
}
],
"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-55WG-FV83-2V8J
Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2025-02-14 18:30In the Linux kernel, the following vulnerability has been resolved:
ocfs2: Avoid touching renamed directory if parent does not change
The VFS will not be locking moved directory if its parent does not change. Change ocfs2 rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem.
{
"affected": [],
"aliases": [
"CVE-2023-52590"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T07:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: Avoid touching renamed directory if parent does not change\n\nThe VFS will not be locking moved directory if its parent does not\nchange. Change ocfs2 rename code to avoid touching renamed directory if\nits parent does not change as without locking that can corrupt the\nfilesystem.",
"id": "GHSA-55wg-fv83-2v8j",
"modified": "2025-02-14T18:30:45Z",
"published": "2024-03-06T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52590"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d618d19b29c2943527e3a43da0a35aea91062fc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de940cede3c41624e2de27f805b490999f419df9"
}
],
"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-568P-FV33-8R9X
Vulnerability from github – Published: 2025-12-08 18:30 – Updated: 2025-12-08 21:30In processLaunchBrowser of CommandParamsFactory.java, there is a possible browser interaction from the lockscreen due to improper locking. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2025-48618"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-08T17:16:18Z",
"severity": "MODERATE"
},
"details": "In processLaunchBrowser of CommandParamsFactory.java, there is a possible browser interaction from the lockscreen due to improper locking. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-568p-fv33-8r9x",
"modified": "2025-12-08T21:30:21Z",
"published": "2025-12-08T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48618"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/opt/telephony/+/fee68bcdcf029e8f40980616d09367610544bc62"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-56C5-8GC7-WJ67
Vulnerability from github – Published: 2025-05-08 09:30 – Updated: 2026-09-14 12:31In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix WARNING "do not call blocking ops when !TASK_RUNNING"
wait_event_timeout() will set the state of the current task to TASK_UNINTERRUPTIBLE, before doing the condition check. This means that ksmbd_durable_scavenger_alive() will try to acquire the mutex while already in a sleeping state. The scheduler warns us by giving the following warning:
do not call blocking ops when !TASK_RUNNING; state=2 set at [<0000000061515a6f>] prepare_to_wait_event+0x9f/0x6c0 WARNING: CPU: 2 PID: 4147 at kernel/sched/core.c:10099 __might_sleep+0x12f/0x160
mutex lock is not needed in ksmbd_durable_scavenger_alive().
{
"affected": [],
"aliases": [
"CVE-2025-37802"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-08T07:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix WARNING \"do not call blocking ops when !TASK_RUNNING\"\n\nwait_event_timeout() will set the state of the current\ntask to TASK_UNINTERRUPTIBLE, before doing the condition check. This\nmeans that ksmbd_durable_scavenger_alive() will try to acquire the mutex\nwhile already in a sleeping state. The scheduler warns us by giving\nthe following warning:\n\ndo not call blocking ops when !TASK_RUNNING; state=2 set at\n [\u003c0000000061515a6f\u003e] prepare_to_wait_event+0x9f/0x6c0\nWARNING: CPU: 2 PID: 4147 at kernel/sched/core.c:10099 __might_sleep+0x12f/0x160\n\nmutex lock is not needed in ksmbd_durable_scavenger_alive().",
"id": "GHSA-56c5-8gc7-wj67",
"modified": "2026-09-14T12:31:26Z",
"published": "2025-05-08T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37802"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1df0d4c616138784e033ad337961b6e1a6bcd999"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8f805b3746d2f41702c77cba22f94f8415fadd1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/97aabdbf7ba82da20e698f0e62917fb206d42941"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd161198e091e8a62b9bd631be970ea9a87d2d6a"
}
],
"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-57PC-F5J8-25X4
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-24 18:30In the Linux kernel, the following vulnerability has been resolved:
can: bcm: fix locking for bcm_op runtime updates
Commit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().
Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.
{
"affected": [],
"aliases": [
"CVE-2026-23362"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:35Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: fix locking for bcm_op runtime updates\n\nCommit c2aba69d0c36 (\"can: bcm: add locking for bcm_op runtime updates\")\nadded a locking for some variables that can be modified at runtime when\nupdating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().\n\nUsually the RX_SETUP only handles and filters incoming traffic with one\nexception: When the RX_RTR_FRAME flag is set a predefined CAN frame is\nsent when a specific RTR frame is received. Therefore the rx bcm_op uses\nbcm_can_tx() which uses the bcm_tx_lock that was only initialized in\nbcm_tx_setup(). Add the missing spin_lock_init() when allocating the\nbcm_op in bcm_rx_setup() to handle the RTR case properly.",
"id": "GHSA-57pc-f5j8-25x4",
"modified": "2026-04-24T18:30:40Z",
"published": "2026-03-25T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23362"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0904037e713f787d1376e1d349c3bdf6c3105881"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70e951afad4c025261fe3c952d2b07237e320a01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/800f26f11ae37b17f58e0001f28a47dd75c26557"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8215ba7bc99e84e66fd6938874ec4330a9d96518"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8bcf2d847adb82b2c617456f6da17ac5e6c75285"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c35636e91e392e1540949bbc67932167cb48bc3a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c85b96eaf766d8f066b1139a17a51efa2f6627ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f0c349b2c21b220af5ba19f29b885e222958d796"
}
],
"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-5822-38R8-R5P2
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-11-08 18:30In the Linux kernel, the following vulnerability has been resolved:
driver core: Fix uevent_show() vs driver detach race
uevent_show() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct device_driver).dev_groups. Instead, the anti-pattern of taking the device_lock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock.
This deadlock is typically invisible to lockdep given the device_lock() is marked lockdep_set_novalidate_class(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form:
====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N
modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220
but task is already holding lock: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronize_rcu() in module_remove_driver() to close any potential races. It is potentially overkill to suffer synchronize_rcu() just to handle the rare module removal racing uevent_show() event.
Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].
{
"affected": [],
"aliases": [
"CVE-2024-44952"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T19:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: Fix uevent_show() vs driver detach race\n\nuevent_show() wants to de-reference dev-\u003edriver-\u003ename. There is no clean\nway for a device attribute to de-reference dev-\u003edriver unless that\nattribute is defined via (struct device_driver).dev_groups. Instead, the\nanti-pattern of taking the device_lock() in the attribute handler risks\ndeadlocks with code paths that remove device attributes while holding\nthe lock.\n\nThis deadlock is typically invisible to lockdep given the device_lock()\nis marked lockdep_set_novalidate_class(), but some subsystems allocate a\nlocal lockdep key for @dev-\u003emutex to reveal reports of the form:\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 6.10.0-rc7+ #275 Tainted: G OE N\n ------------------------------------------------------\n modprobe/2374 is trying to acquire lock:\n ffff8c2270070de0 (kn-\u003eactive#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220\n\n but task is already holding lock:\n ffff8c22016e88f8 (\u0026cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #1 (\u0026cxl_root_key){+.+.}-{3:3}:\n __mutex_lock+0x99/0xc30\n uevent_show+0xac/0x130\n dev_attr_show+0x18/0x40\n sysfs_kf_seq_show+0xac/0xf0\n seq_read_iter+0x110/0x450\n vfs_read+0x25b/0x340\n ksys_read+0x67/0xf0\n do_syscall_64+0x75/0x190\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n -\u003e #0 (kn-\u003eactive#6){++++}-{0:0}:\n __lock_acquire+0x121a/0x1fa0\n lock_acquire+0xd6/0x2e0\n kernfs_drain+0x1e9/0x200\n __kernfs_remove+0xde/0x220\n kernfs_remove_by_name_ns+0x5e/0xa0\n device_del+0x168/0x410\n device_unregister+0x13/0x60\n devres_release_all+0xb8/0x110\n device_unbind_cleanup+0xe/0x70\n device_release_driver_internal+0x1c7/0x210\n driver_detach+0x47/0x90\n bus_remove_driver+0x6c/0xf0\n cxl_acpi_exit+0xc/0x11 [cxl_acpi]\n __do_sys_delete_module.isra.0+0x181/0x260\n do_syscall_64+0x75/0x190\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe observation though is that driver objects are typically much longer\nlived than device objects. It is reasonable to perform lockless\nde-reference of a @driver pointer even if it is racing detach from a\ndevice. Given the infrequency of driver unregistration, use\nsynchronize_rcu() in module_remove_driver() to close any potential\nraces. It is potentially overkill to suffer synchronize_rcu() just to\nhandle the rare module removal racing uevent_show() event.\n\nThanks to Tetsuo Handa for the debug analysis of the syzbot report [1].",
"id": "GHSA-5822-38r8-r5p2",
"modified": "2024-11-08T18:30:43Z",
"published": "2024-09-04T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44952"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15fffc6a5624b13b428bb1c6e9088e32a55eb82c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1cfc329304617838dc06f021bbbde3bc79cd655e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4749d336170dbb629e515a857e58a82e61c37a9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49ea4e0d862632d51667da5e7a9c88a560e9c5a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a7c2a8387524942171037e70b80e969c3b5c05b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4d035c743c3e391728a6f81cbf0f7f9ca700cf62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92d847a35e1e41bceba13b8ac1f0e1b9dbe30d25"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c23fc327d6ec67629b4ad323bd64d3834c0417d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd490a247ddf325325fd0de8898659400c9237ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cfc72b86fa20cbf44d2b6cc27b35eb15080232ab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4dba9a076838f3d0333a6a66efec2cdda90b2ee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd98c9630b7ee273da87e9a244f94ddf947161e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f098e8fc7227166206256c18d56ab622039108b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fd28d9589460945985ef5333e9b942c4261f0826"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fe10c8367687c27172a10ba5cc849bd82077bd7d"
}
],
"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-58VG-W4WX-WP6P
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-19 21:31In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context
The current use of a mutex to protect the notifier hashtable accesses can lead to issues in the atomic context. It results in the below kernel warnings:
| BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | handle_notif_callbacks+0x54/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20
To address this, replace the mutex with an rwlock to protect the notifier hashtable accesses. This ensures that read-side locking does not sleep and multiple readers can acquire the lock concurrently, avoiding unnecessary contention and potential deadlocks. Writer access remains exclusive, preserving correctness.
This change resolves warnings from lockdep about potential sleep in atomic context.
{
"affected": [],
"aliases": [
"CVE-2025-38388"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_ffa: Replace mutex with rwlock to avoid sleep in atomic context\n\nThe current use of a mutex to protect the notifier hashtable accesses\ncan lead to issues in the atomic context. It results in the below\nkernel warnings:\n\n | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258\n | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0\n | preempt_count: 1, expected: 0\n | RCU nest depth: 0, expected: 0\n | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0 #4\n | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn\n | Call trace:\n | show_stack+0x18/0x24 (C)\n | dump_stack_lvl+0x78/0x90\n | dump_stack+0x18/0x24\n | __might_resched+0x114/0x170\n | __might_sleep+0x48/0x98\n | mutex_lock+0x24/0x80\n | handle_notif_callbacks+0x54/0xe0\n | notif_get_and_handle+0x40/0x88\n | generic_exec_single+0x80/0xc0\n | smp_call_function_single+0xfc/0x1a0\n | notif_pcpu_irq_work_fn+0x2c/0x38\n | process_one_work+0x14c/0x2b4\n | worker_thread+0x2e4/0x3e0\n | kthread+0x13c/0x210\n | ret_from_fork+0x10/0x20\n\nTo address this, replace the mutex with an rwlock to protect the notifier\nhashtable accesses. This ensures that read-side locking does not sleep and\nmultiple readers can acquire the lock concurrently, avoiding unnecessary\ncontention and potential deadlocks. Writer access remains exclusive,\npreserving correctness.\n\nThis change resolves warnings from lockdep about potential sleep in\natomic context.",
"id": "GHSA-58vg-w4wx-wp6p",
"modified": "2025-11-19T21:31:16Z",
"published": "2025-07-25T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38388"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/31405510a48dcf054abfa5b7b8d70ce1b27d1f13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8986f8f61b482c0e6efd28f0b2423d9640c20eb1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ca7a421229bbdfbe2e1e628cff5cfa782720a10"
}
],
"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-59G4-MVCC-7P3X
Vulnerability from github – Published: 2025-04-16 15:34 – Updated: 2025-10-31 21:30In the Linux kernel, the following vulnerability has been resolved:
net: ibmveth: make veth_pool_store stop hanging
v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text
Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable.
Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool/. You can do this easily with a little shell script. This causes a hang.
I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw:
Setting pool0/active to 0
Setting pool1/active to 1
[ 73.911067][ T4365] ibmveth 30000002 eth0: close starting
Setting pool1/active to 1
Setting pool1/active to 0
[ 73.911367][ T4366] ibmveth 30000002 eth0: close starting
[ 73.916056][ T4365] ibmveth 30000002 eth0: close complete
[ 73.916064][ T4365] ibmveth 30000002 eth0: open starting
[ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
[ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.
[ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8
[ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000
[ 243.683852][ T123] Call Trace:
[ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)
[ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0
[ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0
[ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210
[ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50
[ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0
[ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60
[ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc
[ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270
[ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0
[ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0
[ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650
[ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150
[ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340
[ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec
...
[ 243.684087][ T123] Showing all locks held in the system:
[ 243.684095][ T123] 1 lock held by khungtaskd/123:
[ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248
[ 243.684114][ T123] 4 locks held by stress.sh/4365:
[ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0
[ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0
[ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60
[ 243.684166][ T123] 5 locks held by stress.sh/4366:
[ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
[ 243.
---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-22053"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:15:58Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ibmveth: make veth_pool_store stop hanging\n\nv2:\n- Created a single error handling unlock and exit in veth_pool_store\n- Greatly expanded commit message with previous explanatory-only text\n\nSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,\nibmveth_close and ibmveth_open, preventing multiple calls in a row to\nnapi_disable.\n\nBackground: Two (or more) threads could call veth_pool_store through\nwriting to /sys/devices/vio/30000002/pool*/*. You can do this easily\nwith a little shell script. This causes a hang.\n\nI configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new\nkernel. I ran this test again and saw:\n\n Setting pool0/active to 0\n Setting pool1/active to 1\n [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting\n Setting pool1/active to 1\n Setting pool1/active to 0\n [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting\n [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete\n [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting\n [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.\n [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8\n [ 243.683833][ T123] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000\n [ 243.683852][ T123] Call Trace:\n [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)\n [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0\n [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0\n [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210\n [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50\n [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0\n [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60\n [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc\n [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270\n [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0\n [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0\n [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650\n [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150\n [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340\n [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec\n ...\n [ 243.684087][ T123] Showing all locks held in the system:\n [ 243.684095][ T123] 1 lock held by khungtaskd/123:\n [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248\n [ 243.684114][ T123] 4 locks held by stress.sh/4365:\n [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n [ 243.684132][ T123] #1: c000000041aea888 (\u0026of-\u003emutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0\n [ 243.684143][ T123] #2: c0000000366fb9a8 (kn-\u003eactive#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0\n [ 243.684155][ T123] #3: c000000035ff4cb8 (\u0026dev-\u003elock){+.+.}-{3:3}, at: napi_enable+0x30/0x60\n [ 243.684166][ T123] 5 locks held by stress.sh/4366:\n [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n [ 243.\n---truncated---",
"id": "GHSA-59g4-mvcc-7p3x",
"modified": "2025-10-31T21:30:54Z",
"published": "2025-04-16T15:34:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22053"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/053f3ff67d7feefc75797863f3d84b47ad47086f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0a2470e3ecde64fc7e3781dc474923193621ae67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e458c292f4c687dcf5aad32dd4836d03cd2191f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86cc70f5c85dc09bf7f3e1eee380eefe73c90765"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a88bb092f4208355880b9fdcc69d491aa297595"
}
],
"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.