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.
727 vulnerabilities reference this CWE, most recent first.
GHSA-X2MC-JWGP-H2FQ
Vulnerability from github – Published: 2024-03-01 00:30 – Updated: 2025-01-09 18:32In the Linux kernel, the following vulnerability has been resolved:
mtd: require write permissions for locking and badblock ioctls
MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once.
MEMSETBADBLOCK modifies the bad block table.
{
"affected": [],
"aliases": [
"CVE-2021-47055"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T23:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: require write permissions for locking and badblock ioctls\n\nMEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require\nwrite permission. Depending on the hardware MEMLOCK might even be\nwrite-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK\nis always write-once.\n\nMEMSETBADBLOCK modifies the bad block table.",
"id": "GHSA-x2mc-jwgp-h2fq",
"modified": "2025-01-09T18:32:06Z",
"published": "2024-03-01T00:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47055"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/077259f5e777c3c8821f6b41dee709fcda27306b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e97743fd180981bef5f01402342bb54bf1c6366"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5880afefe0cb9b2d5e801816acd58bfe91a96981"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/75ed985bd6c8ac1d4e673e93ea9d96c9908c1d37"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b6552719c0ccbbea29dde4be141da54fdb5877e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9625b00cac6630479c0ff4b9fafa88bee636e1f0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a08799d3e8c8088640956237c183f83463c39668"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4d28d8b9b0e7c4ae04214b8d7e0b0466ec6bcaf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f73b29819c6314c0ba8b7d5892dfb03487424bee"
}
],
"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-X33W-8476-HWM3
Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-28 15:30In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: fix circular locking dependency in nci_close_device
nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too:
nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock)
Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN.
NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs.
{
"affected": [],
"aliases": [
"CVE-2026-31509"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T14:16:49Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: fix circular locking dependency in nci_close_device\n\nnci_close_device() flushes rx_wq and tx_wq while holding req_lock.\nThis causes a circular locking dependency because nci_rx_work()\nrunning on rx_wq can end up taking req_lock too:\n\n nci_rx_work -\u003e nci_rx_data_packet -\u003e nci_data_exchange_complete\n -\u003e __sk_destruct -\u003e rawsock_destruct -\u003e nfc_deactivate_target\n -\u003e nci_deactivate_target -\u003e nci_request -\u003e mutex_lock(\u0026ndev-\u003ereq_lock)\n\nMove the flush of rx_wq after req_lock has been released.\nThis should safe (I think) because NCI_UP has already been cleared\nand the transport is closed, so the work will see it and return\n-ENETDOWN.\n\nNIPA has been hitting this running the nci selftest with a debug\nkernel on roughly 4% of the runs.",
"id": "GHSA-x33w-8476-hwm3",
"modified": "2026-04-28T15:30:47Z",
"published": "2026-04-22T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31509"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09143c0e8f3b03517e6233aad42f45c794d8df8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1edc12d2bbcb7a8d0f1088e6fccb9d8c01bb1289"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4527025d440ce84bf56e75ce1df2e84cb8178616"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5eef9ebec7f5738f12cadede3545c05b34bf5ac3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ed00a3edc8597fe2333f524401e2889aa1b5edf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ca54e904a071aa65ef3ad46ba42d51aaac6b73b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d89b74bf08f067b55c03d7f999ba0a0e73177eb3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb435d150ca74b4d40f77f1a2266f3636ed64a79"
}
],
"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-X3R6-6FXJ-5F4R
Vulnerability from github – Published: 2024-12-28 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
usb: musb: Fix hardware lockup on first Rx endpoint request
There is a possibility that a request's callback could be invoked from usb_ep_queue() (call trace below, supplemented with missing calls):
req->complete from usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request from musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart from musb_ep_restart_resume_work (drivers/usb/musb/musb_gadget.c:1176) musb_ep_restart_resume_work from musb_queue_resume_work (drivers/usb/musb/musb_core.c:2279) musb_queue_resume_work from musb_gadget_queue (drivers/usb/musb/musb_gadget.c:1241) musb_gadget_queue from usb_ep_queue (drivers/usb/gadget/udc/core.c:300)
According to the docstring of usb_ep_queue(), this should not happen:
"Note that @req's ->complete() callback must never be called from within usb_ep_queue() as that can create deadlock situations."
In fact, a hardware lockup might occur in the following sequence:
- The gadget is initialized using musb_gadget_enable().
- Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt.
- If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an empty queue (next_request() returns NULL). The interrupt flag has already been cleared by the glue layer handler, but the RXPKTRDY flag remains set.
- The first request is enqueued using usb_ep_queue(), leading to the call of req->complete(), as shown in the call trace above.
- If the callback enables IRQs and another packet is waiting, step (3) repeats. The request queue is empty because usb_g_giveback() removes the request before invoking the callback.
- The endpoint remains locked up, as the interrupt triggered by hardware setting the RXPKTRDY flag has been handled, but the flag itself remains set.
For this scenario to occur, it is only necessary for IRQs to be enabled at some point during the complete callback. This happens with the USB Ethernet gadget, whose rx_complete() callback calls netif_rx(). If called in the task context, netif_rx() disables the bottom halves (BHs). When the BHs are re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The gadget itself is initialized at module load (or at boot if built-in), but the first request is enqueued when the network interface is brought up, triggering rx_complete() in the task context via ioctl(). If a packet arrives while the interface is down, it can prevent the interface from receiving any further packets from the USB host.
The situation is quite complicated with many parties involved. This particular issue can be resolved in several possible ways:
- Ensure that callbacks never enable IRQs. This would be difficult to enforce, as discovering how netif_rx() interacts with interrupts was already quite challenging and u_ether is not the only function driver. Similar "bugs" could be hidden in other drivers as well.
- Disable MUSB interrupts in musb_g_giveback() before calling the callback and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(), for example). This would ensure that MUSB interrupts are not handled during the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However, this feels like an inelegant hack.
- Modify the interrupt handler to clear the RXPKTRDY flag if the request queue is empty. While this approach also feels like a hack, it wastes CPU time by attempting to handle incoming packets when the software is not ready to process them.
- Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart(). This ensures that the hardware can receive packets when there is at least one request in the queue. Once I ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-56687"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-28T10:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: musb: Fix hardware lockup on first Rx endpoint request\n\nThere is a possibility that a request\u0027s callback could be invoked from\nusb_ep_queue() (call trace below, supplemented with missing calls):\n\nreq-\u003ecomplete from usb_gadget_giveback_request\n\t(drivers/usb/gadget/udc/core.c:999)\nusb_gadget_giveback_request from musb_g_giveback\n\t(drivers/usb/musb/musb_gadget.c:147)\nmusb_g_giveback from rxstate\n\t(drivers/usb/musb/musb_gadget.c:784)\nrxstate from musb_ep_restart\n\t(drivers/usb/musb/musb_gadget.c:1169)\nmusb_ep_restart from musb_ep_restart_resume_work\n\t(drivers/usb/musb/musb_gadget.c:1176)\nmusb_ep_restart_resume_work from musb_queue_resume_work\n\t(drivers/usb/musb/musb_core.c:2279)\nmusb_queue_resume_work from musb_gadget_queue\n\t(drivers/usb/musb/musb_gadget.c:1241)\nmusb_gadget_queue from usb_ep_queue\n\t(drivers/usb/gadget/udc/core.c:300)\n\nAccording to the docstring of usb_ep_queue(), this should not happen:\n\n\"Note that @req\u0027s -\u003ecomplete() callback must never be called from within\nusb_ep_queue() as that can create deadlock situations.\"\n\nIn fact, a hardware lockup might occur in the following sequence:\n\n1. The gadget is initialized using musb_gadget_enable().\n2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an\n interrupt.\n3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an\n empty queue (next_request() returns NULL). The interrupt flag has\n already been cleared by the glue layer handler, but the RXPKTRDY flag\n remains set.\n4. The first request is enqueued using usb_ep_queue(), leading to the call\n of req-\u003ecomplete(), as shown in the call trace above.\n5. If the callback enables IRQs and another packet is waiting, step (3)\n repeats. The request queue is empty because usb_g_giveback() removes the\n request before invoking the callback.\n6. The endpoint remains locked up, as the interrupt triggered by hardware\n setting the RXPKTRDY flag has been handled, but the flag itself remains\n set.\n\nFor this scenario to occur, it is only necessary for IRQs to be enabled at\nsome point during the complete callback. This happens with the USB Ethernet\ngadget, whose rx_complete() callback calls netif_rx(). If called in the\ntask context, netif_rx() disables the bottom halves (BHs). When the BHs are\nre-enabled, IRQs are also enabled to allow soft IRQs to be processed. The\ngadget itself is initialized at module load (or at boot if built-in), but\nthe first request is enqueued when the network interface is brought up,\ntriggering rx_complete() in the task context via ioctl(). If a packet\narrives while the interface is down, it can prevent the interface from\nreceiving any further packets from the USB host.\n\nThe situation is quite complicated with many parties involved. This\nparticular issue can be resolved in several possible ways:\n\n1. Ensure that callbacks never enable IRQs. This would be difficult to\n enforce, as discovering how netif_rx() interacts with interrupts was\n already quite challenging and u_ether is not the only function driver.\n Similar \"bugs\" could be hidden in other drivers as well.\n2. Disable MUSB interrupts in musb_g_giveback() before calling the callback\n and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(),\n for example). This would ensure that MUSB interrupts are not handled\n during the callback, even if IRQs are enabled. In fact, it would allow\n IRQs to be enabled when releasing the lock. However, this feels like an\n inelegant hack.\n3. Modify the interrupt handler to clear the RXPKTRDY flag if the request\n queue is empty. While this approach also feels like a hack, it wastes\n CPU time by attempting to handle incoming packets when the software is\n not ready to process them.\n4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart().\n This ensures that the hardware can receive packets when there is at\n least one request in the queue. Once I\n---truncated---",
"id": "GHSA-x3r6-6fxj-5f4r",
"modified": "2025-11-03T21:32:01Z",
"published": "2024-12-28T12:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56687"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c89445e6d475b78d37b64ae520831cd43af7db4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fc137386c4620305bbc2a216868c53f9245670a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5906ee3693674d734177df13a519a21bb03f730d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c749500b28cae67410792096133ee7f282439c51"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f05ad9755bb294328c3d0f429164ac6d4d08c548"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/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-X3XP-7X67-4CX9
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-05 17:48In the Linux kernel, the following vulnerability has been resolved:
PM: hibernate: Avoid deadlock in hibernate_compressor_param_set()
syzbot reported a deadlock in lock_system_sleep() (see below).
The write operation to "/sys/module/hibernate/parameters/compressor" conflicts with the registration of ieee80211 device, resulting in a deadlock when attempting to acquire system_transition_mutex under param_lock.
To avoid this deadlock, change hibernate_compressor_param_set() to use mutex_trylock() for attempting to acquire system_transition_mutex and return -EBUSY when it fails.
Task flags need not be saved or adjusted before calling mutex_trylock(&system_transition_mutex) because the caller is not going to end up waiting for this mutex and if it runs concurrently with system suspend in progress, it will be frozen properly when it returns to user space.
syzbot report:
syz-executor895/5833 is trying to acquire lock: ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56
but task is already holding lock: ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline] ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (param_lock){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline] rate_control_alloc net/mac80211/rate.c:266 [inline] ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558 init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910 do_one_initcall+0x128/0x700 init/main.c:1257 do_initcall_level init/main.c:1319 [inline] do_initcalls init/main.c:1335 [inline] do_basic_setup init/main.c:1354 [inline] kernel_init_freeable+0x5c7/0x900 init/main.c:1568 kernel_init+0x1c/0x2b0 init/main.c:1457 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
-> #2 (rtnl_mutex){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 wg_pm_notification drivers/net/wireguard/device.c:80 [inline] wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64 notifier_call_chain+0xb7/0x410 kernel/notifier.c:85 notifier_call_chain_robust kernel/notifier.c:120 [inline] blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline] blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333 pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 drivers/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [inline] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [inline] __do_sys_openat fs/open.c:1459 [inline] __se_sys_openat fs/open.c:1454 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #1 ((pm_chain_head).rwsem){++++}-{4:4}: down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 blocking_notifier_call_chain_robust kerne ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-37745"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPM: hibernate: Avoid deadlock in hibernate_compressor_param_set()\n\nsyzbot reported a deadlock in lock_system_sleep() (see below).\n\nThe write operation to \"/sys/module/hibernate/parameters/compressor\"\nconflicts with the registration of ieee80211 device, resulting in a deadlock\nwhen attempting to acquire system_transition_mutex under param_lock.\n\nTo avoid this deadlock, change hibernate_compressor_param_set() to use\nmutex_trylock() for attempting to acquire system_transition_mutex and\nreturn -EBUSY when it fails.\n\nTask flags need not be saved or adjusted before calling\nmutex_trylock(\u0026system_transition_mutex) because the caller is not going\nto end up waiting for this mutex and if it runs concurrently with system\nsuspend in progress, it will be frozen properly when it returns to user\nspace.\n\nsyzbot report:\n\nsyz-executor895/5833 is trying to acquire lock:\nffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, at: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56\n\nbut task is already holding lock:\nffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: kernel_param_lock kernel/params.c:607 [inline]\nffffffff8e07dc68 (param_lock){+.+.}-{4:4}, at: param_attr_store+0xe6/0x300 kernel/params.c:586\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #3 (param_lock){+.+.}-{4:4}:\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730\n ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [inline]\n rate_control_alloc net/mac80211/rate.c:266 [inline]\n ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015\n ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531\n mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558\n init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910\n do_one_initcall+0x128/0x700 init/main.c:1257\n do_initcall_level init/main.c:1319 [inline]\n do_initcalls init/main.c:1335 [inline]\n do_basic_setup init/main.c:1354 [inline]\n kernel_init_freeable+0x5c7/0x900 init/main.c:1568\n kernel_init+0x1c/0x2b0 init/main.c:1457\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\n-\u003e #2 (rtnl_mutex){+.+.}-{4:4}:\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730\n wg_pm_notification drivers/net/wireguard/device.c:80 [inline]\n wg_pm_notification+0x49/0x180 drivers/net/wireguard/device.c:64\n notifier_call_chain+0xb7/0x410 kernel/notifier.c:85\n notifier_call_chain_robust kernel/notifier.c:120 [inline]\n blocking_notifier_call_chain_robust kernel/notifier.c:345 [inline]\n blocking_notifier_call_chain_robust+0xc9/0x170 kernel/notifier.c:333\n pm_notifier_call_chain_robust+0x27/0x60 kernel/power/main.c:102\n snapshot_open+0x189/0x2b0 kernel/power/user.c:77\n misc_open+0x35a/0x420 drivers/char/misc.c:179\n chrdev_open+0x237/0x6a0 fs/char_dev.c:414\n do_dentry_open+0x735/0x1c40 fs/open.c:956\n vfs_open+0x82/0x3f0 fs/open.c:1086\n do_open fs/namei.c:3830 [inline]\n path_openat+0x1e88/0x2d80 fs/namei.c:3989\n do_filp_open+0x20c/0x470 fs/namei.c:4016\n do_sys_openat2+0x17a/0x1e0 fs/open.c:1428\n do_sys_open fs/open.c:1443 [inline]\n __do_sys_openat fs/open.c:1459 [inline]\n __se_sys_openat fs/open.c:1454 [inline]\n __x64_sys_openat+0x175/0x210 fs/open.c:1454\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n-\u003e #1 ((pm_chain_head).rwsem){++++}-{4:4}:\n down_read+0x9a/0x330 kernel/locking/rwsem.c:1524\n blocking_notifier_call_chain_robust kerne\n---truncated---",
"id": "GHSA-x3xp-7x67-4cx9",
"modified": "2025-11-05T17:48:22Z",
"published": "2025-05-01T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37745"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/11ae4fec1f4b4ee06770a572c37d89cbaecbf66e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b2c3806ef4253595dfcb8b58352cfab55c9bfb0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52323ed1444ea5c2a5f1754ea0a2d9c8c216ccdf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6dbaa8583af74814a5aae03a337cb1722c414808"
}
],
"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-X465-6XX8-6H3C
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2026-01-07 18:30In the Linux kernel, the following vulnerability has been resolved:
hfsplus: remove mutex_lock check in hfsplus_free_extents
Syzbot reported an issue in hfsplus filesystem:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0 Call Trace: hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606 hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56 cont_expand_zero fs/buffer.c:2383 [inline] cont_write_begin+0x2cf/0x860 fs/buffer.c:2446 hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52 generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347 hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263 notify_change+0xe38/0x10f0 fs/attr.c:420 do_truncate+0x1fb/0x2e0 fs/open.c:65 do_sys_ftruncate+0x2eb/0x380 fs/open.c:193 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") unlock extree before hfsplus_free_extents(), and add check wheather extree is locked in hfsplus_free_extents().
However, when operations such as hfsplus_file_release, hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed concurrently in different files, it is very likely to trigger the WARN_ON, which will lead syzbot and xfstest to consider it as an abnormality.
The comment above this warning also describes one of the easy triggering situations, which can easily trigger and cause xfstest&syzbot to report errors.
[task A] [task B] ->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!
Several threads could try to lock the shared extents tree. And warning can be triggered in one thread when another thread has locked the tree. This is the wrong behavior of the code and we need to remove the warning.
{
"affected": [],
"aliases": [
"CVE-2025-38650"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:39Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: remove mutex_lock check in hfsplus_free_extents\n\nSyzbot reported an issue in hfsplus filesystem:\n\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346\n\thfsplus_free_extents+0x700/0xad0\nCall Trace:\n\u003cTASK\u003e\nhfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606\nhfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56\ncont_expand_zero fs/buffer.c:2383 [inline]\ncont_write_begin+0x2cf/0x860 fs/buffer.c:2446\nhfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52\ngeneric_cont_expand_simple+0x151/0x250 fs/buffer.c:2347\nhfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263\nnotify_change+0xe38/0x10f0 fs/attr.c:420\ndo_truncate+0x1fb/0x2e0 fs/open.c:65\ndo_sys_ftruncate+0x2eb/0x380 fs/open.c:193\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nTo avoid deadlock, Commit 31651c607151 (\"hfsplus: avoid deadlock\non file truncation\") unlock extree before hfsplus_free_extents(),\nand add check wheather extree is locked in hfsplus_free_extents().\n\nHowever, when operations such as hfsplus_file_release,\nhfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed\nconcurrently in different files, it is very likely to trigger the\nWARN_ON, which will lead syzbot and xfstest to consider it as an\nabnormality.\n\nThe comment above this warning also describes one of the easy\ntriggering situations, which can easily trigger and cause\nxfstest\u0026syzbot to report errors.\n\n[task A]\t\t\t[task B]\n-\u003ehfsplus_file_release\n -\u003ehfsplus_file_truncate\n -\u003ehfs_find_init\n -\u003emutex_lock\n -\u003emutex_unlock\n\t\t\t\t-\u003ehfsplus_write_begin\n\t\t\t\t -\u003ehfsplus_get_block\n\t\t\t\t -\u003ehfsplus_file_extend\n\t\t\t\t -\u003ehfsplus_ext_read_extent\n\t\t\t\t -\u003ehfs_find_init\n\t\t\t\t\t -\u003emutex_lock\n -\u003ehfsplus_free_extents\n WARN_ON(mutex_is_locked) !!!\n\nSeveral threads could try to lock the shared extents tree.\nAnd warning can be triggered in one thread when another thread\nhas locked the tree. This is the wrong behavior of the code and\nwe need to remove the warning.",
"id": "GHSA-x465-6xx8-6h3c",
"modified": "2026-01-07T18:30:21Z",
"published": "2025-08-22T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38650"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0807e4ac59a546f2346961c5e26a98901594b205"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/084933961ecda7561dedfb78c4676ccb90c91ada"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14922f0cc92e010b160121679c0a6ca072f4e975"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/314310166ba1fdff7660dfd9d18ea42d7058f7ae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5055b7db94110f228961dea6b74eed0a93a50b01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9764b8bb9f5f94df105cd2ac43829dd0d2c82b9f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a19ce9230b22a0866313932e7964cf05557a6008"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcb96956c921f1aae7e7b477f2435c56f77a31b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fdd6aca652122d6e97787e88d7dd53ddc8b74e7e"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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-X4V6-W9V4-P32J
Vulnerability from github – Published: 2024-01-17 18:31 – Updated: 2024-01-24 21:30A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.
{
"affected": [],
"aliases": [
"CVE-2024-0641"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-833"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-17T16:15:47Z",
"severity": "MODERATE"
},
"details": "A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel\u2019s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.",
"id": "GHSA-x4v6-w9v4-p32j",
"modified": "2024-01-24T21:30:32Z",
"published": "2024-01-17T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0641"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-0641"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2258757"
}
],
"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-X4W2-GH57-R677
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2025-03-13 18:32In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix deadlock when freeing cgroup storage
The following commit bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]") first introduced deadlock prevention for fentry/fexit programs attaching on bpf_task_storage helpers. That commit also employed the logic in map free path in its v6 version.
Later bpf_cgrp_storage was first introduced in c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs") which faces the same issue as bpf_task_storage, instead of its busy counter, NULL was passed to bpf_local_storage_map_free() which opened a window to cause deadlock:
<TASK>
(acquiring local_storage->lock)
_raw_spin_lock_irqsave+0x3d/0x50
bpf_local_storage_update+0xd1/0x460
bpf_cgrp_storage_get+0x109/0x130
bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170
? __bpf_prog_enter_recur+0x16/0x80
bpf_trampoline_6442485186+0x43/0xa4
cgroup_storage_ptr+0x9/0x20
(holding local_storage->lock)
bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160
bpf_selem_unlink_storage+0x6f/0x110
bpf_local_storage_map_free+0xa2/0x110
bpf_map_free_deferred+0x5b/0x90
process_one_work+0x17c/0x390
worker_thread+0x251/0x360
kthread+0xd2/0x100
ret_from_fork+0x34/0x50
ret_from_fork_asm+0x1a/0x30
</TASK>
Progs: - A: SEC("fentry/cgroup_storage_ptr") - cgid (BPF_MAP_TYPE_HASH) Record the id of the cgroup the current task belonging to in this hash map, using the address of the cgroup as the map key. - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE) If current task is a kworker, lookup the above hash map using function parameter @owner as the key to get its corresponding cgroup id which is then used to get a trusted pointer to the cgroup through bpf_cgroup_from_id(). This trusted pointer can then be passed to bpf_cgrp_storage_get() to finally trigger the deadlock issue. - B: SEC("tp_btf/sys_enter") - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE) The only purpose of this prog is to fill Prog A's hash map by calling bpf_cgrp_storage_get() for as many userspace tasks as possible.
Steps to reproduce: - Run A; - while (true) { Run B; Destroy B; }
Fix this issue by passing its busy counter to the free procedure so it can be properly incremented before storage/smap locking.
{
"affected": [],
"aliases": [
"CVE-2024-58088"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock when freeing cgroup storage\n\nThe following commit\nbc235cdb423a (\"bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]\")\nfirst introduced deadlock prevention for fentry/fexit programs attaching\non bpf_task_storage helpers. That commit also employed the logic in map\nfree path in its v6 version.\n\nLater bpf_cgrp_storage was first introduced in\nc4bcfb38a95e (\"bpf: Implement cgroup storage available to non-cgroup-attached bpf progs\")\nwhich faces the same issue as bpf_task_storage, instead of its busy\ncounter, NULL was passed to bpf_local_storage_map_free() which opened\na window to cause deadlock:\n\n\t\u003cTASK\u003e\n\t\t(acquiring local_storage-\u003elock)\n\t_raw_spin_lock_irqsave+0x3d/0x50\n\tbpf_local_storage_update+0xd1/0x460\n\tbpf_cgrp_storage_get+0x109/0x130\n\tbpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170\n\t? __bpf_prog_enter_recur+0x16/0x80\n\tbpf_trampoline_6442485186+0x43/0xa4\n\tcgroup_storage_ptr+0x9/0x20\n\t\t(holding local_storage-\u003elock)\n\tbpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160\n\tbpf_selem_unlink_storage+0x6f/0x110\n\tbpf_local_storage_map_free+0xa2/0x110\n\tbpf_map_free_deferred+0x5b/0x90\n\tprocess_one_work+0x17c/0x390\n\tworker_thread+0x251/0x360\n\tkthread+0xd2/0x100\n\tret_from_fork+0x34/0x50\n\tret_from_fork_asm+0x1a/0x30\n\t\u003c/TASK\u003e\n\nProgs:\n - A: SEC(\"fentry/cgroup_storage_ptr\")\n - cgid (BPF_MAP_TYPE_HASH)\n\tRecord the id of the cgroup the current task belonging\n\tto in this hash map, using the address of the cgroup\n\tas the map key.\n - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)\n\tIf current task is a kworker, lookup the above hash\n\tmap using function parameter @owner as the key to get\n\tits corresponding cgroup id which is then used to get\n\ta trusted pointer to the cgroup through\n\tbpf_cgroup_from_id(). This trusted pointer can then\n\tbe passed to bpf_cgrp_storage_get() to finally trigger\n\tthe deadlock issue.\n - B: SEC(\"tp_btf/sys_enter\")\n - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)\n\tThe only purpose of this prog is to fill Prog A\u0027s\n\thash map by calling bpf_cgrp_storage_get() for as\n\tmany userspace tasks as possible.\n\nSteps to reproduce:\n - Run A;\n - while (true) { Run B; Destroy B; }\n\nFix this issue by passing its busy counter to the free procedure so\nit can be properly incremented before storage/smap locking.",
"id": "GHSA-x4w2-gh57-r677",
"modified": "2025-03-13T18:32:20Z",
"published": "2025-03-12T12:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58088"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ecb9fa14eec5f15d97c84c36896871335f6ddfb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c78f4afbd962f43a3989f45f3ca04300252b19b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fac674d2bd68f3479f27328626b42d1eebd11fef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcec95b4ab3e7bc6b2f36e5d59f7e24104ea87f7"
}
],
"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-X5CV-7H6W-46HM
Vulnerability from github – Published: 2026-04-03 15:30 – Updated: 2026-04-24 15:32In the Linux kernel, the following vulnerability has been resolved:
wifi: wlcore: Fix a locking bug
Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.
{
"affected": [],
"aliases": [
"CVE-2026-23420"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T14:16:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wlcore: Fix a locking bug\n\nMake sure that wl-\u003emutex is locked before it is unlocked. This has been\ndetected by the Clang thread-safety analyzer.",
"id": "GHSA-x5cv-7h6w-46hm",
"modified": "2026-04-24T15:32:21Z",
"published": "2026-04-03T15:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23420"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1a1c28a08d74716f3f8e3a21c86b30d0ff13521a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ae8faf31b24c78653f4433298ee52813a56967a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5feeea59ed142e15c3284d0b1a364c6786bf3487"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/72c6df8f284b3a49812ce2ac136727ace70acc7c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ab511003c5ae3bf5364d7699a2e3ab1db513680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aca4c9e4901b01b8b985993dc7df80bd1d1338bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc404390a386404cf9822d4091ccae1f61efcbcd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcef983ad88832f3aa83491a174c345de57afbbd"
}
],
"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-X5FC-MWCH-J73R
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2025-01-10 18:31In the Linux kernel, the following vulnerability has been resolved:
mwifiex: bring down link before deleting interface
We can deadlock when rmmod'ing the driver or going through firmware reset, because the cfg80211_unregister_wdev() has to bring down the link for us, ... which then grab the same wiphy lock.
nl80211_del_interface() already handles a very similar case, with a nice description:
/*
* We hold RTNL, so this is safe, without RTNL opencount cannot
* reach 0, and thus the rdev cannot be deleted.
*
* We need to do it for the dev_close(), since that will call
* the netdev notifiers, and we need to acquire the mutex there
* but don't know if we get there from here or from some other
* place (e.g. "ip link set ... down").
*/
mutex_unlock(&rdev->wiphy.mtx);
...
Do similarly for mwifiex teardown, by ensuring we bring the link down first.
Sample deadlock trace:
[ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds. [ 247.110630] Not tainted 5.12.4 #5 [ 247.115796] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208 [ 247.133905] Call trace: [ 247.136644] __switch_to+0x130/0x170 [ 247.140643] __schedule+0x714/0xa0c [ 247.144548] schedule_preempt_disabled+0x88/0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lock_nested+0x5c/0x68 [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211] [ 247.165769] raw_notifier_call_chain+0x4c/0x78 [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4 [ 247.176305] __dev_close_many+0x7c/0x138 [ 247.180693] dev_close_many+0x7c/0x10c [ 247.184893] unregister_netdevice_many+0xfc/0x654 [ 247.190158] unregister_netdevice_queue+0xb4/0xe0 [ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211] [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211] [ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex] [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex] [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex] [ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie] [ 247.231451] pci_device_remove+0x50/0xe0 [ 247.235849] device_release_driver_internal+0x110/0x1b0 [ 247.241701] driver_detach+0x5c/0x9c [ 247.245704] bus_remove_driver+0x84/0xb8 [ 247.250095] driver_unregister+0x3c/0x60 [ 247.254486] pci_unregister_driver+0x2c/0x90 [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie]
{
"affected": [],
"aliases": [
"CVE-2021-47349"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:21Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmwifiex: bring down link before deleting interface\n\nWe can deadlock when rmmod\u0027ing the driver or going through firmware\nreset, because the cfg80211_unregister_wdev() has to bring down the link\nfor us, ... which then grab the same wiphy lock.\n\nnl80211_del_interface() already handles a very similar case, with a nice\ndescription:\n\n /*\n * We hold RTNL, so this is safe, without RTNL opencount cannot\n * reach 0, and thus the rdev cannot be deleted.\n *\n * We need to do it for the dev_close(), since that will call\n * the netdev notifiers, and we need to acquire the mutex there\n * but don\u0027t know if we get there from here or from some other\n * place (e.g. \"ip link set ... down\").\n */\n mutex_unlock(\u0026rdev-\u003ewiphy.mtx);\n...\n\nDo similarly for mwifiex teardown, by ensuring we bring the link down\nfirst.\n\nSample deadlock trace:\n\n[ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds.\n[ 247.110630] Not tainted 5.12.4 #5\n[ 247.115796] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208\n[ 247.133905] Call trace:\n[ 247.136644] __switch_to+0x130/0x170\n[ 247.140643] __schedule+0x714/0xa0c\n[ 247.144548] schedule_preempt_disabled+0x88/0xf4\n[ 247.149714] __mutex_lock_common+0x43c/0x750\n[ 247.154496] mutex_lock_nested+0x5c/0x68\n[ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211]\n[ 247.165769] raw_notifier_call_chain+0x4c/0x78\n[ 247.170742] call_netdevice_notifiers_info+0x68/0xa4\n[ 247.176305] __dev_close_many+0x7c/0x138\n[ 247.180693] dev_close_many+0x7c/0x10c\n[ 247.184893] unregister_netdevice_many+0xfc/0x654\n[ 247.190158] unregister_netdevice_queue+0xb4/0xe0\n[ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211]\n[ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211]\n[ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex]\n[ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex]\n[ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex]\n[ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie]\n[ 247.231451] pci_device_remove+0x50/0xe0\n[ 247.235849] device_release_driver_internal+0x110/0x1b0\n[ 247.241701] driver_detach+0x5c/0x9c\n[ 247.245704] bus_remove_driver+0x84/0xb8\n[ 247.250095] driver_unregister+0x3c/0x60\n[ 247.254486] pci_unregister_driver+0x2c/0x90\n[ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie]",
"id": "GHSA-x5fc-mwch-j73r",
"modified": "2025-01-10T18:31:37Z",
"published": "2024-05-21T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47349"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f9482aa8d412b4ba06ce6ab8e333fb8ca29a06e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/35af69c7c0490fdccfc159c6a87e4d1dc070838a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a3041d39d3c14da97fa3476835aba043ba810cf0"
}
],
"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-X5VM-26PP-XFF5
Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
btrfs: lock the inode in shared mode before starting fiemap
Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following:
task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52737"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T16:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: lock the inode in shared mode before starting fiemap\n\nCurrently fiemap does not take the inode\u0027s lock (VFS lock), it only locks\na file range in the inode\u0027s io tree. This however can lead to a deadlock\nif we have a concurrent fsync on the file and fiemap code triggers a fault\nwhen accessing the user space buffer with fiemap_fill_next_extent(). The\ndeadlock happens on the inode\u0027s i_mmap_lock semaphore, which is taken both\nby fsync and btrfs_page_mkwrite(). This deadlock was recently reported by\nsyzbot and triggers a trace like the following:\n\n task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004\n Call Trace:\n \u003cTASK\u003e\n context_switch kernel/sched/core.c:5293 [inline]\n __schedule+0x995/0xe20 kernel/sched/core.c:6606\n schedule+0xcb/0x190 kernel/sched/core.c:6682\n wait_on_state fs/btrfs/extent-io-tree.c:707 [inline]\n wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751\n lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742\n find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488\n writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863\n __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174\n extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091\n extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211\n do_writepages+0x3c3/0x680 mm/page-writeback.c:2581\n filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388\n __filemap_fdatawrite_range mm/filemap.c:421 [inline]\n filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439\n btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline]\n start_ordered_ops fs/btrfs/file.c:1737 [inline]\n btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839\n generic_write_sync include/linux/fs.h:2885 [inline]\n btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684\n call_write_iter include/linux/fs.h:2189 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7f7d4054e9b9\n RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9\n RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006\n RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69\n R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8\n \u003c/TASK\u003e\n INFO: task syz-executor361:5697 blocked for more than 145 seconds.\n Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004\n Call Trace:\n \u003cTASK\u003e\n context_switch kernel/sched/core.c:5293 [inline]\n __schedule+0x995/0xe20 kernel/sched/core.c:6606\n schedule+0xcb/0x190 kernel/sched/core.c:6682\n rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095\n __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260\n btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526\n do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947\n wp_page_shared+0x15e/0x380 mm/memory.c:3295\n handle_pte_fault mm/memory.c:4949 [inline]\n __handle_mm_fault mm/memory.c:5073 [inline]\n handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219\n do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428\n handle_page_fault arch/x86/mm/fault.c:1519 [inline]\n exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575\n asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570\n RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233\n Code: 74 0a 89 (...)\n RSP: 0018:ffffc9000570f330 EFLAGS: 000502\n---truncated---",
"id": "GHSA-x5vm-26pp-xff5",
"modified": "2026-06-01T18:31:18Z",
"published": "2024-05-21T18:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52737"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/519b7e13b5ae8dd38da1e52275705343be6bb508"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d8c594da79bc0244e610a70594e824a401802be1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e425191073a80906d8502b5179471cc58b0b9e9a"
}
],
"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.