CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
693 vulnerabilities reference this CWE, most recent first.
GHSA-3WWR-WV4X-4GXG
Vulnerability from github – Published: 2024-03-18 12:30 – Updated: 2024-12-12 15:31In the Linux kernel, the following vulnerability has been resolved:
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks.
Fix this by using a stack buffer when calling copy_to_user.
{
"affected": [],
"aliases": [
"CVE-2023-52615"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-18T11:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: core - Fix page fault dead lock on mmap-ed hwrng\n\nThere is a dead-lock in the hwrng device read path. This triggers\nwhen the user reads from /dev/hwrng into memory also mmap-ed from\n/dev/hwrng. The resulting page fault triggers a recursive read\nwhich then dead-locks.\n\nFix this by using a stack buffer when calling copy_to_user.",
"id": "GHSA-3wwr-wv4x-4gxg",
"modified": "2024-12-12T15:31:06Z",
"published": "2024-03-18T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52615"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-3XVM-4G57-GVJ6
Vulnerability from github – Published: 2023-07-23 03:30 – Updated: 2024-04-04 06:19A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat.
{
"affected": [],
"aliases": [
"CVE-2023-2430"
],
"database_specific": {
"cwe_ids": [
"CWE-413",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-23T02:15:11Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat.",
"id": "GHSA-3xvm-4g57-gvj6",
"modified": "2024-04-04T06:19:26Z",
"published": "2023-07-23T03:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2430"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5492"
}
],
"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-435P-F446-GXF4
Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix a deadlock problem when config TC during resetting
When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable()
In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.
{
"affected": [],
"aliases": [
"CVE-2024-44995"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T20:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix a deadlock problem when config TC during resetting\n\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n pf reset start\n \u2502\n \u25bc\n ......\nsetup tc \u2502\n \u2502 \u25bc\n \u25bc DOWN: napi_disable()\nnapi_disable()(skip) \u2502\n \u2502 \u2502\n \u25bc \u25bc\n ...... ......\n \u2502 \u2502\n \u25bc \u2502\nnapi_enable() \u2502\n \u25bc\n UINIT: netif_napi_del()\n \u2502\n \u25bc\n ......\n \u2502\n \u25bc\n INIT: netif_napi_add()\n \u2502\n \u25bc\n ...... global reset start\n \u2502 \u2502\n \u25bc \u25bc\n UP: napi_enable()(skip) ......\n \u2502 \u2502\n \u25bc \u25bc\n ...... napi_disable()\n\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.",
"id": "GHSA-435p-f446-gxf4",
"modified": "2025-11-04T00:31:23Z",
"published": "2024-09-04T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44995"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ced30a109"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-437H-4CV6-6Q92
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-12-23 21:30In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: Do a runtime PM get on controllers during probe
mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack:
CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()
CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()
Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression.
Verified on MT8183 and MT8192 Chromebooks.
{
"affected": [],
"aliases": [
"CVE-2024-27002"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: mediatek: Do a runtime PM get on controllers during probe\n\nmt8183-mfgcfg has a mutual dependency with genpd during the probing\nstage, which leads to a deadlock in the following call stack:\n\nCPU0: genpd_lock --\u003e clk_prepare_lock\ngenpd_power_off_work_fn()\n genpd_lock()\n generic_pm_domain::power_off()\n clk_unprepare()\n clk_prepare_lock()\n\nCPU1: clk_prepare_lock --\u003e genpd_lock\nclk_register()\n __clk_core_init()\n clk_prepare_lock()\n clk_pm_runtime_get()\n genpd_lock()\n\nDo a runtime PM get at the probe function to make sure clk_register()\nwon\u0027t acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,\ndo this on all mediatek clock controller probings because we don\u0027t\nbelieve this would cause any regression.\n\nVerified on MT8183 and MT8192 Chromebooks.",
"id": "GHSA-437h-4cv6-6q92",
"modified": "2024-12-23T21:30:50Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27002"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
}
],
"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-443G-XXFV-37VX
Vulnerability from github – Published: 2025-03-27 18:31 – Updated: 2025-04-15 18:31In the Linux kernel, the following vulnerability has been resolved:
mm/swapfile: add cond_resched() in get_swap_pages()
The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently.
The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup.
{
"affected": [],
"aliases": [
"CVE-2023-52932"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swapfile: add cond_resched() in get_swap_pages()\n\nThe softlockup still occurs in get_swap_pages() under memory pressure. 64\nCPU cores, 64GB memory, and 28 zram devices, the disksize of each zram\ndevice is 50MB with same priority as si. Use the stress-ng tool to\nincrease memory pressure, causing the system to oom frequently.\n\nThe plist_for_each_entry_safe() loops in get_swap_pages() could reach tens\nof thousands of times to find available space (extreme case:\ncond_resched() is not called in scan_swap_map_slots()). Let\u0027s add\ncond_resched() into get_swap_pages() when failed to find available space\nto avoid softlockup.",
"id": "GHSA-443g-xxfv-37vx",
"modified": "2025-04-15T18:31:42Z",
"published": "2025-03-27T18:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52932"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29f0349c5c76b627fe06b87d4b13fa03a6ce8e64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/30187be29052bba9203b0ae2bdd815e0bc2faaab"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/387217b97e99699c34e6d95ce2b91b327fcd853e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49178d4d61e78aed8c837dfeea8a450700f196e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5dbe1ebd56470d03b78fc31491a9e4d433106ef2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7717fc1a12f88701573f9ed897cc4f6699c661e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d49c85a1913385eed46dd16a25ad0928253767f0"
}
],
"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-4457-8Q65-98HW
Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-11-26 00:30In the Linux kernel, the following vulnerability has been resolved:
net: hibmcge: fix rtnl deadlock issue
Currently, the hibmcge netdev acquires the rtnl_lock in pci_error_handlers.reset_prepare() and releases it in pci_error_handlers.reset_done().
However, in the PCI framework: pci_reset_bus - __pci_reset_slot - pci_slot_save_and_disable_locked - pci_dev_save_and_disable - err_handler->reset_prepare(dev);
In pci_slot_save_and_disable_locked(): list_for_each_entry(dev, &slot->bus->devices, bus_list) { if (!dev->slot || dev->slot!= slot) continue; pci_dev_save_and_disable(dev); if (dev->subordinate) pci_bus_save_and_disable_locked(dev->subordinate); }
This will iterate through all devices under the current bus and execute err_handler->reset_prepare(), causing two devices of the hibmcge driver to sequentially request the rtnl_lock, leading to a deadlock.
Since the driver now executes netif_device_detach() before the reset process, it will not concurrently with other netdev APIs, so there is no need to hold the rtnl_lock now.
Therefore, this patch removes the rtnl_lock during the reset process and adjusts the position of HBG_NIC_STATE_RESETTING to ensure that multiple resets are not executed concurrently.
{
"affected": [],
"aliases": [
"CVE-2025-38720"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-04T16:15:41Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hibmcge: fix rtnl deadlock issue\n\nCurrently, the hibmcge netdev acquires the rtnl_lock in\npci_error_handlers.reset_prepare() and releases it in\npci_error_handlers.reset_done().\n\nHowever, in the PCI framework:\npci_reset_bus - __pci_reset_slot - pci_slot_save_and_disable_locked -\n pci_dev_save_and_disable - err_handler-\u003ereset_prepare(dev);\n\nIn pci_slot_save_and_disable_locked():\n\tlist_for_each_entry(dev, \u0026slot-\u003ebus-\u003edevices, bus_list) {\n\t\tif (!dev-\u003eslot || dev-\u003eslot!= slot)\n\t\t\tcontinue;\n\t\tpci_dev_save_and_disable(dev);\n\t\tif (dev-\u003esubordinate)\n\t\t\tpci_bus_save_and_disable_locked(dev-\u003esubordinate);\n\t}\n\nThis will iterate through all devices under the current bus and execute\nerr_handler-\u003ereset_prepare(), causing two devices of the hibmcge driver\nto sequentially request the rtnl_lock, leading to a deadlock.\n\nSince the driver now executes netif_device_detach()\nbefore the reset process, it will not concurrently with\nother netdev APIs, so there is no need to hold the rtnl_lock now.\n\nTherefore, this patch removes the rtnl_lock during the reset process and\nadjusts the position of HBG_NIC_STATE_RESETTING to ensure\nthat multiple resets are not executed concurrently.",
"id": "GHSA-4457-8q65-98hw",
"modified": "2025-11-26T00:30:16Z",
"published": "2025-09-05T18:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38720"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1343a8994ca7dba78f5dd818e89d68331c21c35d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c875503a9b9082928d7d3fc60b5400d16fbfae4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d85a6346fd6f595c4914205762d0cdf35c004a5e"
}
],
"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-448G-F6XX-9XFW
Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2025-10-31 18:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()
The documentation for usb_driver_claim_interface() says that "the device lock" is needed when the function is called from places other than probe(). This appears to be the lock for the USB interface device. The Mediatek btusb code gets called via this path:
Workqueue: hci0 hci_power_on [bluetooth] Call trace: usb_driver_claim_interface btusb_mtk_claim_iso_intf btusb_mtk_setup hci_dev_open_sync hci_power_on process_scheduled_works worker_thread kthread
With the above call trace the device lock hasn't been claimed. Claim it.
Without this fix, we'd sometimes see the error "Failed to claim iso
interface". Sometimes we'd even see worse errors, like a NULL pointer
dereference (where intf->dev.driver was NULL) with a trace like:
Call trace: usb_suspend_both usb_runtime_suspend __rpm_callback rpm_suspend pm_runtime_work process_scheduled_works
Both errors appear to be fixed with the proper locking.
{
"affected": [],
"aliases": [
"CVE-2025-21827"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-06T16:15:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\n\nThe documentation for usb_driver_claim_interface() says that \"the\ndevice lock\" is needed when the function is called from places other\nthan probe(). This appears to be the lock for the USB interface\ndevice. The Mediatek btusb code gets called via this path:\n\n Workqueue: hci0 hci_power_on [bluetooth]\n Call trace:\n usb_driver_claim_interface\n btusb_mtk_claim_iso_intf\n btusb_mtk_setup\n hci_dev_open_sync\n hci_power_on\n process_scheduled_works\n worker_thread\n kthread\n\nWith the above call trace the device lock hasn\u0027t been claimed. Claim\nit.\n\nWithout this fix, we\u0027d sometimes see the error \"Failed to claim iso\ninterface\". Sometimes we\u0027d even see worse errors, like a NULL pointer\ndereference (where `intf-\u003edev.driver` was NULL) with a trace like:\n\n Call trace:\n usb_suspend_both\n usb_runtime_suspend\n __rpm_callback\n rpm_suspend\n pm_runtime_work\n process_scheduled_works\n\nBoth errors appear to be fixed with the proper locking.",
"id": "GHSA-448g-f6xx-9xfw",
"modified": "2025-10-31T18:31:10Z",
"published": "2025-03-06T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21827"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4194766ec8756f4f654d595ae49962acbac49490"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/930e1790b99e5839e1af69d2f7fd808f1fba2df9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e9087e828827e5a5c85e124ce77503f2b81c3491"
}
],
"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-44F9-RXJ6-P8RG
Vulnerability from github – Published: 2026-06-03 18:33 – Updated: 2026-06-09 21:32In the Linux kernel, the following vulnerability has been resolved:
NFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages
LOCALIO is an NFS loopback mount optimization that avoids using the network for READ, WRITE and COMMIT if the NFS client and server are determined to be on the same system. But because LOCALIO is still fundamentally "just NFS loopback mount" it is susceptible to recursion deadlock via direct reclaim, e.g.: NFS LOCALIO down to XFS and then back into NFS via nfs_writepages.
Fix LOCALIO's potential for direct reclaim deadlock by ensuring that all its page cache allocations are done from GFP_NOFS context.
Thanks to Ben Coddington for pointing out commit ad22c7a043c2 ("xfs: prevent stack overflows from page cache allocation").
{
"affected": [],
"aliases": [
"CVE-2026-46256"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-03T18:16:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFS/localio: prevent direct reclaim recursion into NFS via nfs_writepages\n\nLOCALIO is an NFS loopback mount optimization that avoids using the\nnetwork for READ, WRITE and COMMIT if the NFS client and server are\ndetermined to be on the same system. But because LOCALIO is still\nfundamentally \"just NFS loopback mount\" it is susceptible to recursion\ndeadlock via direct reclaim, e.g.: NFS LOCALIO down to XFS and then\nback into NFS via nfs_writepages.\n\nFix LOCALIO\u0027s potential for direct reclaim deadlock by ensuring that\nall its page cache allocations are done from GFP_NOFS context.\n\nThanks to Ben Coddington for pointing out commit ad22c7a043c2 (\"xfs:\nprevent stack overflows from page cache allocation\").",
"id": "GHSA-44f9-rxj6-p8rg",
"modified": "2026-06-09T21:32:21Z",
"published": "2026-06-03T18:33:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46256"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67435d2d8a33a75f9647724952cb1b18279d2e95"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a5de0c4fc0f217eea945d3d72c34ee30d72cbc9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ae26a4cf2baf0a44c538dc093504d1994b02dade"
}
],
"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-44X6-67XW-4M95
Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2025-03-25 15:31In the Linux kernel, the following vulnerability has been resolved:
bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT
In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT is enabled.
[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs [ 35.118569] preempt_count: 1, expected: 0 [ 35.118571] RCU nest depth: 1, expected: 1 [ 35.118577] INFO: lockdep is turned off. ... [ 35.118647] __might_resched+0x433/0x5b0 [ 35.118677] rt_spin_lock+0xc3/0x290 [ 35.118700] slaballoc+0x72/0xc40 [ 35.118723] kmalloc_noprof+0x13f/0x4e0 [ 35.118732] bpf_map_kzalloc+0xe5/0x220 [ 35.118740] bpf_selem_alloc+0x1d2/0x7b0 [ 35.118755] bpf_local_storage_update+0x2fa/0x8b0 [ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0 [ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66 [ 35.118795] bpf_trace_run3+0x222/0x400 [ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20 [ 35.118824] trace_inet_sock_set_state+0x112/0x130 [ 35.118830] inet_sk_state_store+0x41/0x90 [ 35.118836] tcp_set_state+0x3b3/0x640
There is no need to adjust the gfp_flags passing to the bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL. The verifier has ensured GFP_KERNEL is passed only in sleepable context.
It has been an old issue since the first introduction of the bpf_local_storage ~5 years ago, so this patch targets the bpf-next.
bpf_mem_alloc is needed to solve it, so the Fixes tag is set to the commit when bpf_mem_alloc was first used in the bpf_local_storage.
{
"affected": [],
"aliases": [
"CVE-2024-58070"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-06T16:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT\n\nIn PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible\ncontext. bpf_mem_alloc must be used in PREEMPT_RT. This patch is\nto enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT\nis enabled.\n\n[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs\n[ 35.118569] preempt_count: 1, expected: 0\n[ 35.118571] RCU nest depth: 1, expected: 1\n[ 35.118577] INFO: lockdep is turned off.\n ...\n[ 35.118647] __might_resched+0x433/0x5b0\n[ 35.118677] rt_spin_lock+0xc3/0x290\n[ 35.118700] ___slab_alloc+0x72/0xc40\n[ 35.118723] __kmalloc_noprof+0x13f/0x4e0\n[ 35.118732] bpf_map_kzalloc+0xe5/0x220\n[ 35.118740] bpf_selem_alloc+0x1d2/0x7b0\n[ 35.118755] bpf_local_storage_update+0x2fa/0x8b0\n[ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0\n[ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66\n[ 35.118795] bpf_trace_run3+0x222/0x400\n[ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20\n[ 35.118824] trace_inet_sock_set_state+0x112/0x130\n[ 35.118830] inet_sk_state_store+0x41/0x90\n[ 35.118836] tcp_set_state+0x3b3/0x640\n\nThere is no need to adjust the gfp_flags passing to the\nbpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.\nThe verifier has ensured GFP_KERNEL is passed only in sleepable context.\n\nIt has been an old issue since the first introduction of the\nbpf_local_storage ~5 years ago, so this patch targets the bpf-next.\n\nbpf_mem_alloc is needed to solve it, so the Fixes tag is set\nto the commit when bpf_mem_alloc was first used in the bpf_local_storage.",
"id": "GHSA-44x6-67xw-4m95",
"modified": "2025-03-25T15:31:22Z",
"published": "2025-03-06T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58070"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3392fa605d7c5708c5fbe02e4fbdac547c3b7352"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8eef6ac4d70eb1f0099fff93321d90ce8fa49ee1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b0027500000dfcb8ee952557d565064cea22c43e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1d398a3af7e59d7fef351c84fed7ebb575d1f1a"
}
],
"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-456M-93FM-GFF2
Vulnerability from github – Published: 2025-07-25 15:30 – Updated: 2025-11-19 21:31In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix potential deadlock in MR deregistration
The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock.
The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | → revoke_mr() | → mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | → mutex_lock(&dev->cache.rb_lock) | → mlx5r_cache_create_ent_locked() | → kzalloc(GFP_KERNEL) | → fs_reclaim() | → mmu_notifier_invalidate_range_start() | → mlx5_ib_invalidate_range() | → mutex_lock(&umem_odp->umem_mutex) → cache_ent_find_and_store() | → mutex_lock(&dev->cache.rb_lock) |
Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex.
Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path.
This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path.
The following lockdep warning demonstrates the deadlock:
python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]
but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138
-> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
-> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core]
---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-38373"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T13:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix potential deadlock in MR deregistration\n\nThe issue arises when kzalloc() is invoked while holding umem_mutex or\nany other lock acquired under umem_mutex. This is problematic because\nkzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke\nmmu_notifier_invalidate_range_start(). This function can lead to\nmlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,\nresulting in a deadlock.\n\nThe problematic flow:\n CPU0 | CPU1\n---------------------------------------|------------------------------------------------\nmlx5_ib_dereg_mr() |\n \u2192 revoke_mr() |\n \u2192 mutex_lock(\u0026umem_odp-\u003eumem_mutex) |\n | mlx5_mkey_cache_init()\n | \u2192 mutex_lock(\u0026dev-\u003ecache.rb_lock)\n | \u2192 mlx5r_cache_create_ent_locked()\n | \u2192 kzalloc(GFP_KERNEL)\n | \u2192 fs_reclaim()\n | \u2192 mmu_notifier_invalidate_range_start()\n | \u2192 mlx5_ib_invalidate_range()\n | \u2192 mutex_lock(\u0026umem_odp-\u003eumem_mutex)\n \u2192 cache_ent_find_and_store() |\n \u2192 mutex_lock(\u0026dev-\u003ecache.rb_lock) |\n\nAdditionally, when kzalloc() is called from within\ncache_ent_find_and_store(), we encounter the same deadlock due to\nre-acquisition of umem_mutex.\n\nSolve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()\nand before acquiring rb_lock. This ensures that we don\u0027t hold\numem_mutex while performing memory allocations that could trigger\nthe reclaim path.\n\nThis change prevents the deadlock by ensuring proper lock ordering and\navoiding holding locks during memory allocation operations that could\ntrigger the reclaim path.\n\nThe following lockdep warning demonstrates the deadlock:\n\n python3/20557 is trying to acquire lock:\n ffff888387542128 (\u0026umem_odp-\u003eumem_mutex){+.+.}-{4:4}, at:\n mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]\n\n but task is already holding lock:\n ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:\n unmap_vmas+0x7b/0x1a0\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n fs_reclaim_acquire+0x60/0xd0\n mem_cgroup_css_alloc+0x6f/0x9b0\n cgroup_init_subsys+0xa4/0x240\n cgroup_init+0x1c8/0x510\n start_kernel+0x747/0x760\n x86_64_start_reservations+0x25/0x30\n x86_64_start_kernel+0x73/0x80\n common_startup_64+0x129/0x138\n\n -\u003e #2 (fs_reclaim){+.+.}-{0:0}:\n fs_reclaim_acquire+0x91/0xd0\n __kmalloc_cache_noprof+0x4d/0x4c0\n mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]\n mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]\n mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]\n __mlx5_ib_add+0x4b/0x190 [mlx5_ib]\n mlx5r_probe+0xd9/0x320 [mlx5_ib]\n auxiliary_bus_probe+0x42/0x70\n really_probe+0xdb/0x360\n __driver_probe_device+0x8f/0x130\n driver_probe_device+0x1f/0xb0\n __driver_attach+0xd4/0x1f0\n bus_for_each_dev+0x79/0xd0\n bus_add_driver+0xf0/0x200\n driver_register+0x6e/0xc0\n __auxiliary_driver_register+0x6a/0xc0\n do_one_initcall+0x5e/0x390\n do_init_module+0x88/0x240\n init_module_from_file+0x85/0xc0\n idempotent_init_module+0x104/0x300\n __x64_sys_finit_module+0x68/0xc0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n -\u003e #1 (\u0026dev-\u003ecache.rb_lock){+.+.}-{4:4}:\n __mutex_lock+0x98/0xf10\n __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]\n mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]\n ib_dereg_mr_user+0x85/0x1f0 [ib_core]\n \n---truncated---",
"id": "GHSA-456m-93fm-gff2",
"modified": "2025-11-19T21:31:16Z",
"published": "2025-07-25T15:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38373"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2ed25aa7f7711f508b6120e336f05cd9d49943c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/727eb1be65a370572edf307558ec3396b8573156"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/beb89ada5715e7bd1518c58863eedce89ec051a7"
}
],
"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.