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.
733 vulnerabilities reference this CWE, most recent first.
GHSA-F5WJ-8Q5W-FQWR
Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-06-16 03:30In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix deadlock in jbd2_journal_cancel_revoke()
Commit f76d4c28a46a ("fs/jbd2: use sleeping version of __find_get_block()") changed jbd2_journal_cancel_revoke() to use __find_get_block_nonatomic() which holds the folio lock instead of i_private_lock. This breaks the lock ordering (folio -> buffer) and causes an ABBA deadlock when the filesystem blocksize < pagesize:
T1 T2
ext4_mkdir() ext4_init_new_dir() ext4_append() ext4_getblk() lock_buffer() <- A sync_blockdev() blkdev_writepages() writeback_iter() writeback_get_folio() folio_lock() <- B ext4_journal_get_create_access() jbd2_journal_cancel_revoke() __find_get_block_nonatomic() folio_lock() <- B block_write_full_folio() lock_buffer() <- A
This can occasionally cause generic/013 to hang.
Fix by only calling __find_get_block_nonatomic() when the passed buffer_head doesn't belong to the bdev, which is the only case that we need to look up its bdev alias. Otherwise, the lookup is redundant since the found buffer_head is equal to the one we passed in.
{
"affected": [],
"aliases": [
"CVE-2026-46061"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T14:17:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: fix deadlock in jbd2_journal_cancel_revoke()\n\nCommit f76d4c28a46a (\"fs/jbd2: use sleeping version of\n__find_get_block()\") changed jbd2_journal_cancel_revoke() to use\n__find_get_block_nonatomic() which holds the folio lock instead of\ni_private_lock. This breaks the lock ordering (folio -\u003e buffer) and\ncauses an ABBA deadlock when the filesystem blocksize \u003c pagesize:\n\n T1 T2\next4_mkdir()\n ext4_init_new_dir()\n ext4_append()\n ext4_getblk()\n lock_buffer() \u003c- A\n sync_blockdev()\n blkdev_writepages()\n writeback_iter()\n writeback_get_folio()\n folio_lock() \u003c- B\n ext4_journal_get_create_access()\n jbd2_journal_cancel_revoke()\n __find_get_block_nonatomic()\n folio_lock() \u003c- B\n block_write_full_folio()\n lock_buffer() \u003c- A\n\nThis can occasionally cause generic/013 to hang.\n\nFix by only calling __find_get_block_nonatomic() when the passed\nbuffer_head doesn\u0027t belong to the bdev, which is the only case that we\nneed to look up its bdev alias. Otherwise, the lookup is redundant since\nthe found buffer_head is equal to the one we passed in.",
"id": "GHSA-f5wj-8q5w-fqwr",
"modified": "2026-06-16T03:30:33Z",
"published": "2026-05-27T15:33:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46061"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b2fee890250ab647a601124471a334bb01a0790"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/981fcc5674e67158d24d23e841523eccba19d0e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbd943d6a2d566428324b516a37f98328dfb802d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dff07cc98fdf6af57a7c054dc09b2050a9d5c287"
}
],
"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-F5WR-JGGW-QG46
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-17 21:31In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential deadlock in __driver_attach
In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach").
stack like commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). list below: In __driver_attach function, The lock holding logic is as follows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); / when fail or work limit, sync to execute func, but __driver_attach_async_helper will get lock dev as will, which will lead to A-A deadlock. / if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev)
As above show, when it is allowed to do async probes, because of
out of memory or work limit, async work is not be allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__driver_attach_async_helper getting lock dev.
Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like below:
[ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00004000 [ 370.788865] Call Trace: [ 370.789374] [ 370.789841] __schedule+0x482/0x1050 [ 370.790613] schedule+0x92/0x1a0 [ 370.791290] schedule_preempt_disabled+0x2c/0x50 [ 370.792256] __mutex_lock.isra.0+0x757/0xec0 [ 370.793158] __mutex_lock_slowpath+0x1f/0x30 [ 370.794079] mutex_lock+0x50/0x60 [ 370.794795] __device_driver_lock+0x2f/0x70 [ 370.795677] ? driver_probe_device+0xd0/0xd0 [ 370.796576] __driver_attach_async_helper+0x1d/0xd0 [ 370.797318] ? driver_probe_device+0xd0/0xd0 [ 370.797957] async_schedule_node_domain+0xa5/0xc0 [ 370.798652] async_schedule_node+0x19/0x30 [ 370.799243] __driver_attach+0x246/0x290 [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0 [ 370.800548] bus_for_each_dev+0x9d/0x130 [ 370.801132] driver_attach+0x22/0x30 [ 370.801666] bus_add_driver+0x290/0x340 [ 370.802246] driver_register+0x88/0x140 [ 370.802817] ? virtio_scsi_init+0x116/0x116 [ 370.803425] scsi_register_driver+0x1a/0x30 [ 370.804057] init_sd+0x184/0x226 [ 370.804533] do_one_initcall+0x71/0x3a0 [ 370.805107] kernel_init_freeable+0x39a/0x43a [ 370.805759] ? rest_init+0x150/0x150 [ 370.806283] kernel_init+0x26/0x230 [ 370.806799] ret_from_fork+0x1f/0x30
To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-50149"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:44Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential deadlock in __driver_attach\n\nIn __driver_attach function, There are also AA deadlock problem,\nlike the commit b232b02bf3c2 (\"driver core: fix deadlock in\n__device_attach\").\n\nstack like commit b232b02bf3c2 (\"driver core: fix deadlock in\n__device_attach\").\nlist below:\n In __driver_attach function, The lock holding logic is as follows:\n ...\n __driver_attach\n if (driver_allows_async_probing(drv))\n device_lock(dev) // get lock dev\n async_schedule_dev(__driver_attach_async_helper, dev); // func\n async_schedule_node\n async_schedule_node_domain(func)\n entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);\n /* when fail or work limit, sync to execute func, but\n __driver_attach_async_helper will get lock dev as\n will, which will lead to A-A deadlock. */\n if (!entry || atomic_read(\u0026entry_count) \u003e MAX_WORK) {\n func;\n else\n queue_work_node(node, system_unbound_wq, \u0026entry-\u003ework)\n device_unlock(dev)\n\n As above show, when it is allowed to do async probes, because of\n out of memory or work limit, async work is not be allowed, to do\n sync execute instead. it will lead to A-A deadlock because of\n __driver_attach_async_helper getting lock dev.\n\nReproduce:\nand it can be reproduce by make the condition\n(if (!entry || atomic_read(\u0026entry_count) \u003e MAX_WORK)) untenable, like\nbelow:\n\n[ 370.785650] \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n[ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:\n0 flags:0x00004000\n[ 370.788865] Call Trace:\n[ 370.789374] \u003cTASK\u003e\n[ 370.789841] __schedule+0x482/0x1050\n[ 370.790613] schedule+0x92/0x1a0\n[ 370.791290] schedule_preempt_disabled+0x2c/0x50\n[ 370.792256] __mutex_lock.isra.0+0x757/0xec0\n[ 370.793158] __mutex_lock_slowpath+0x1f/0x30\n[ 370.794079] mutex_lock+0x50/0x60\n[ 370.794795] __device_driver_lock+0x2f/0x70\n[ 370.795677] ? driver_probe_device+0xd0/0xd0\n[ 370.796576] __driver_attach_async_helper+0x1d/0xd0\n[ 370.797318] ? driver_probe_device+0xd0/0xd0\n[ 370.797957] async_schedule_node_domain+0xa5/0xc0\n[ 370.798652] async_schedule_node+0x19/0x30\n[ 370.799243] __driver_attach+0x246/0x290\n[ 370.799828] ? driver_allows_async_probing+0xa0/0xa0\n[ 370.800548] bus_for_each_dev+0x9d/0x130\n[ 370.801132] driver_attach+0x22/0x30\n[ 370.801666] bus_add_driver+0x290/0x340\n[ 370.802246] driver_register+0x88/0x140\n[ 370.802817] ? virtio_scsi_init+0x116/0x116\n[ 370.803425] scsi_register_driver+0x1a/0x30\n[ 370.804057] init_sd+0x184/0x226\n[ 370.804533] do_one_initcall+0x71/0x3a0\n[ 370.805107] kernel_init_freeable+0x39a/0x43a\n[ 370.805759] ? rest_init+0x150/0x150\n[ 370.806283] kernel_init+0x26/0x230\n[ 370.806799] ret_from_fork+0x1f/0x30\n\nTo fix the deadlock, move the async_schedule_dev outside device_lock,\nas we can see, in async_schedule_node_domain, the parameter of\nqueue_work_node is system_unbound_wq, so it can accept concurrent\noperations. which will also not change the code logic, and will\nnot lead to deadlock.",
"id": "GHSA-f5wr-jggw-qg46",
"modified": "2025-11-17T21:31:18Z",
"published": "2025-06-18T12:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50149"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37f908038402c9b8325763f306a1c65d88757e15"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/70fe758352cafdee72a7b13bf9db065f9613ced8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/733ab0c19bf17f6ad7c2b580ede006e369d5ab1b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/779b634714c51d05baaeff4868ce2fd9fc7399bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8191b6cd9ada09b675f17446d5872eb1f77685cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a93f33aeef4e6a94ae9c9d3f5b2f9085ad0572ec"
}
],
"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-F6FR-V692-H863
Vulnerability from github – Published: 2024-08-17 09:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix missing lock on sync reset reload
On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert like the following:
WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50 … CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50 … Call Trace: ? __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50 devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ? process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 […]
{
"affected": [],
"aliases": [
"CVE-2024-42268"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-17T09:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix missing lock on sync reset reload\n\nOn sync reset reload work, when remote host updates devlink on reload\nactions performed on that host, it misses taking devlink lock before\ncalling devlink_remote_reload_actions_performed() which results in\ntriggering lock assert like the following:\n\nWARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50\n\u2026\n CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116\n Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015\n Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core]\n RIP: 0010:devl_assert_locked+0x3e/0x50\n\u2026\n Call Trace:\n \u003cTASK\u003e\n ? __warn+0xa4/0x210\n ? devl_assert_locked+0x3e/0x50\n ? report_bug+0x160/0x280\n ? handle_bug+0x3f/0x80\n ? exc_invalid_op+0x17/0x40\n ? asm_exc_invalid_op+0x1a/0x20\n ? devl_assert_locked+0x3e/0x50\n devlink_notify+0x88/0x2b0\n ? mlx5_attach_device+0x20c/0x230 [mlx5_core]\n ? __pfx_devlink_notify+0x10/0x10\n ? process_one_work+0x4b6/0xbb0\n process_one_work+0x4b6/0xbb0\n[\u2026]",
"id": "GHSA-f6fr-v692-h863",
"modified": "2025-11-04T00:31:12Z",
"published": "2024-08-17T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42268"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/091268f3c27a5b6d7858a3bb2a0dbcc9cd26ddb5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/572f9caa9e7295f8c8822e4122c7ae8f1c412ff9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5d07d1d40aabfd61bab21115639bd4f641db6002"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98884e89c90d077f6fe6ba18e6cf6f914642f04e"
},
{
"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-F6GG-FR3W-RQH2
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-09-03 18:31In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler
The OTG branch of composite_setup() falls back to the first configuration when none is selected:
if (cdev->config)
config = cdev->config;
else
config = list_first_entry(&cdev->configs,
struct usb_configuration, list);
if (!config)
goto done;
...
memcpy(req->buf, config->descriptors[0], value);
list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the "if (!config)" check is dead.
When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer.
cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch.
Use list_first_entry_or_null() so the existing check does its job.
{
"affected": [],
"aliases": [
"CVE-2026-64347"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: composite: fix dead empty check in the USB_DT_OTG handler\n\nThe OTG branch of composite_setup() falls back to the first\nconfiguration when none is selected:\n\n\tif (cdev-\u003econfig)\n\t\tconfig = cdev-\u003econfig;\n\telse\n\t\tconfig = list_first_entry(\u0026cdev-\u003econfigs,\n\t\t\t\t\t struct usb_configuration, list);\n\tif (!config)\n\t\tgoto done;\n\t...\n\tmemcpy(req-\u003ebuf, config-\u003edescriptors[0], value);\n\nlist_first_entry() never returns NULL. On an empty list it returns\ncontainer_of() of the list head. So the \"if (!config)\" check is dead.\n\nWhen cdev-\u003econfigs is empty, config points at the head inside struct\nusb_composite_dev. config-\u003edescriptors[0] reads whatever sits at that\noffset. The memcpy copies up to w_length bytes of it into the response\nbuffer.\n\ncdev-\u003econfigs can be empty in two cases. One is a teardown race on\ngadget unbind with a control transfer in flight. The other is a driver\nthat sets is_otg before it adds a config. A reproducer that holds\ncdev-\u003econfigs empty triggers a KASAN fault in this branch.\n\nUse list_first_entry_or_null() so the existing check does its job.",
"id": "GHSA-f6gg-fr3w-rqh2",
"modified": "2026-09-03T18:31:17Z",
"published": "2026-07-25T12:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64347"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/01feaf024f29618d5ffa7ab0fd858e0579dcbf7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2454264b2ab4cf0055c0bfd39e79f830452bd0db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56add2b9b2e89ec61c0761165d758f73004fdfdf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ac463fe6c0f85bdb1ce8c30e8c9e060802e4483"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/91b3ecd34b60f950c50c560974945b6596a6f207"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3e72cfef2e38bd588055739a8100d14f9773b17"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f8f680609c2b3ab795ffcd6f21585b6dfc46d395"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcb21bf747640c9d6bd1eda9da85420f076d59c1"
}
],
"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-F6M9-QFP4-RPHW
Vulnerability from github – Published: 2024-07-12 15:31 – Updated: 2025-11-04 00:30In the Linux kernel, the following vulnerability has been resolved:
serial: imx: Introduce timeout when waiting on transmitter empty
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock.
In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue.
{
"affected": [],
"aliases": [
"CVE-2024-40967"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: imx: Introduce timeout when waiting on transmitter empty\n\nBy waiting at most 1 second for USR2_TXDC to be set, we avoid a potential\ndeadlock.\n\nIn case of the timeout, there is not much we can do, so we simply ignore\nthe transmitter state and optimistically try to continue.",
"id": "GHSA-f6m9-qfp4-rphw",
"modified": "2025-11-04T00:30:56Z",
"published": "2024-07-12T15:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40967"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2"
},
{
"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-F6MC-XR5X-M669
Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix locking in .getsockopt
Mirror iucv_sock_setsockopt() and wrap the whole switch in lock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock becomes redundant and is removed.
Any AF_IUCV HIPER user can potentially crash the kernel by racing recvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences iucv->hs_dev->mtu after iucv_sock_close() (called from the racing recvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference oops.
{
"affected": [],
"aliases": [
"CVE-2026-64004"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T16:17:40Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/iucv: fix locking in .getsockopt\n\nMirror iucv_sock_setsockopt() and wrap the whole switch in\nlock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock\nbecomes redundant and is removed.\n\nAny AF_IUCV HIPER user can potentially crash the kernel by racing\nrecvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences\niucv-\u003ehs_dev-\u003emtu after iucv_sock_close() (called from the racing\nrecvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference\noops.",
"id": "GHSA-f6mc-xr5x-m669",
"modified": "2026-07-20T15:31:55Z",
"published": "2026-07-19T18:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64004"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1fc30bd4e55e2dd622d2d366cecd732c1841bbee"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3589d20a666caf30ad100c960a2de7de390fce88"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/45bb8de8c95d8899f4b8f61bd9bceb8132af73cb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69554adc7a6fa04ede3ad7512321d83748e3c920"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e792b8dd3002bbc4136745928a9605df1a72b8a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/884eb247b74d86db97e3a37f0d6fc8e1e83590dd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9817369243380e287ebe5525411557eaa3aa2a79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd691beafea0dd779e69e81ccc26b0ab50efcb5e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F73J-5PGC-V7QJ
Vulnerability from github – Published: 2024-05-17 15:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
dm snapshot: fix lockup in dm_exception_table_exit
There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.
{
"affected": [],
"aliases": [
"CVE-2024-35805"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T14:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm snapshot: fix lockup in dm_exception_table_exit\n\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \"cond_resched\" to the loop that frees the exceptions.",
"id": "GHSA-f73j-5pgc-v7qj",
"modified": "2026-05-12T12:31:46Z",
"published": "2024-05-17T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35805"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/116562e804ffc9dc600adab6326dde31d72262c7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d47eb405781cc5127deca9a14e24b27696087a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5f4ad4d0b0943296287313db60b3f84df4aad683"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9759ff196e7d248bcf8386a7451d6ff8537a7d9c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e50f83061ac250f90710757a3e51b70a200835e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e7d4cff57c3c43fdd72342c78d4138f509c7416e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa5c055800a7fd49a36bbb52593aca4ea986a366"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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-F834-HVGH-G5V9
Vulnerability from github – Published: 2024-04-10 21:30 – Updated: 2024-11-05 00:31In the Linux kernel, the following vulnerability has been resolved:
scsi: core: sysfs: Fix hang when device state is set via sysfs
This fixes a regression added with:
commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after offlinining device")
The problem is that after iSCSI recovery, iscsid will call into the kernel to set the dev's state to running, and with that patch we now call scsi_rescan_device() with the state_mutex held. If the SCSI error handler thread is just starting to test the device in scsi_send_eh_cmnd() then it's going to try to grab the state_mutex.
We are then stuck, because when scsi_rescan_device() tries to send its I/O scsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery() which will return true (the host state is still in recovery) and I/O will just be requeued. scsi_send_eh_cmnd() will then never be able to grab the state_mutex to finish error handling.
To prevent the deadlock move the rescan-related code to after we drop the state_mutex.
This also adds a check for if we are already in the running state. This prevents extra scans and helps the iscsid case where if the transport class has already onlined the device during its recovery process then we don't need userspace to do it again plus possibly block that daemon.
{
"affected": [],
"aliases": [
"CVE-2021-47192"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-10T19:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: sysfs: Fix hang when device state is set via sysfs\n\nThis fixes a regression added with:\n\ncommit f0f82e2476f6 (\"scsi: core: Fix capacity set to zero after\nofflinining device\")\n\nThe problem is that after iSCSI recovery, iscsid will call into the kernel\nto set the dev\u0027s state to running, and with that patch we now call\nscsi_rescan_device() with the state_mutex held. If the SCSI error handler\nthread is just starting to test the device in scsi_send_eh_cmnd() then it\u0027s\ngoing to try to grab the state_mutex.\n\nWe are then stuck, because when scsi_rescan_device() tries to send its I/O\nscsi_queue_rq() calls -\u003e scsi_host_queue_ready() -\u003e scsi_host_in_recovery()\nwhich will return true (the host state is still in recovery) and I/O will\njust be requeued. scsi_send_eh_cmnd() will then never be able to grab the\nstate_mutex to finish error handling.\n\nTo prevent the deadlock move the rescan-related code to after we drop the\nstate_mutex.\n\nThis also adds a check for if we are already in the running state. This\nprevents extra scans and helps the iscsid case where if the transport class\nhas already onlined the device during its recovery process then we don\u0027t\nneed userspace to do it again plus possibly block that daemon.",
"id": "GHSA-f834-hvgh-g5v9",
"modified": "2024-11-05T00:31:26Z",
"published": "2024-04-10T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47192"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F94P-FCWW-CPFJ
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-24 21:31In the Linux kernel, the following vulnerability has been resolved:
can: mcp251x: fix deadlock in error path of mcp251x_open
The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish.
This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but for the error path.
To solve this issue move the call to free_irq() after the lock is
released. Setting priv->force_quit = 1 beforehand ensure that the IRQ
handler will exit right away once it acquired the lock.
{
"affected": [],
"aliases": [
"CVE-2026-23357"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:34Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: mcp251x: fix deadlock in error path of mcp251x_open\n\nThe mcp251x_open() function call free_irq() in its error path with the\nmpc_lock mutex held. But if an interrupt already occurred the\ninterrupt handler will be waiting for the mpc_lock and free_irq() will\ndeadlock waiting for the handler to finish.\n\nThis issue is similar to the one fixed in commit 7dd9c26bd6cf (\"can:\nmcp251x: fix deadlock if an interrupt occurs during mcp251x_open\") but\nfor the error path.\n\nTo solve this issue move the call to free_irq() after the lock is\nreleased. Setting `priv-\u003eforce_quit = 1` beforehand ensure that the IRQ\nhandler will exit right away once it acquired the lock.",
"id": "GHSA-f94p-fcww-cpfj",
"modified": "2026-04-24T21:31:56Z",
"published": "2026-03-25T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23357"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/256f0cff6e946c570392bda1d01a65e789a7afd0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38063cc435b69d56e76f947c10d336fcb2953508"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/416c18ecddafab0ed09be1e7b9d2f448f3d4db16"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/739454057572cb0948658d1142f3fa2c6966465c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ab3f894de216f4a62adc3b57e9191888cbf26885"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b73832292cd914e87a55e863ba4413a907e7db6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d27f12c3f5e85efc479896af4a69eccb37f75e8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e728f444c913a91d290d1824b4770780bbd6378e"
}
],
"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-F95Q-FWQ6-MX8W
Vulnerability from github – Published: 2024-08-21 00:30 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix a deadlock in dma buf fence polling
Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks.
vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock.
dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called.
Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock.
{
"affected": [],
"aliases": [
"CVE-2024-43863"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T00:15:04Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\n\nIntroduce a version of the fence ops that on release doesn\u0027t remove\nthe fence from the pending list, and thus doesn\u0027t require a lock to\nfix poll-\u003efence wait-\u003efence unref deadlocks.\n\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\n\ndma buf polling cb unrefs a fence after it\u0027s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0027s held by the wait from which it\nwas called.\n\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.",
"id": "GHSA-f95q-fwq6-mx8w",
"modified": "2025-11-04T00:31:17Z",
"published": "2024-08-21T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43863"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9908dc0d2ef0e4aec8a242c098455729c0e2f017"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.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"
}
]
}
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.