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.
713 vulnerabilities reference this CWE, most recent first.
GHSA-V82J-FHF7-MWX2
Vulnerability from github – Published: 2024-08-17 09:30 – Updated: 2024-08-19 21:35In the Linux kernel, the following vulnerability has been resolved:
block: fix deadlock between sd_remove & sd_release
Our test report the following hung task:
[ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc
[ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac
T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex)
SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in this scenario. This is a classic ABBA deadlock. To fix the deadlock, make sure we don't try to acquire disk->open_mutex after freezing the queue.
{
"affected": [],
"aliases": [
"CVE-2024-42294"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-17T09:15:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix deadlock between sd_remove \u0026 sd_release\n\nOur test report the following hung task:\n\n[ 2538.459400] INFO: task \"kworker/0:0\":7 blocked for more than 188 seconds.\n[ 2538.459427] Call trace:\n[ 2538.459430] __switch_to+0x174/0x338\n[ 2538.459436] __schedule+0x628/0x9c4\n[ 2538.459442] schedule+0x7c/0xe8\n[ 2538.459447] schedule_preempt_disabled+0x24/0x40\n[ 2538.459453] __mutex_lock+0x3ec/0xf04\n[ 2538.459456] __mutex_lock_slowpath+0x14/0x24\n[ 2538.459459] mutex_lock+0x30/0xd8\n[ 2538.459462] del_gendisk+0xdc/0x350\n[ 2538.459466] sd_remove+0x30/0x60\n[ 2538.459470] device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459474] device_release_driver+0x18/0x28\n[ 2538.459478] bus_remove_device+0x15c/0x174\n[ 2538.459483] device_del+0x1d0/0x358\n[ 2538.459488] __scsi_remove_device+0xa8/0x198\n[ 2538.459493] scsi_forget_host+0x50/0x70\n[ 2538.459497] scsi_remove_host+0x80/0x180\n[ 2538.459502] usb_stor_disconnect+0x68/0xf4\n[ 2538.459506] usb_unbind_interface+0xd4/0x280\n[ 2538.459510] device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459514] device_release_driver+0x18/0x28\n[ 2538.459518] bus_remove_device+0x15c/0x174\n[ 2538.459523] device_del+0x1d0/0x358\n[ 2538.459528] usb_disable_device+0x84/0x194\n[ 2538.459532] usb_disconnect+0xec/0x300\n[ 2538.459537] hub_event+0xb80/0x1870\n[ 2538.459541] process_scheduled_works+0x248/0x4dc\n[ 2538.459545] worker_thread+0x244/0x334\n[ 2538.459549] kthread+0x114/0x1bc\n\n[ 2538.461001] INFO: task \"fsck.\":15415 blocked for more than 188 seconds.\n[ 2538.461014] Call trace:\n[ 2538.461016] __switch_to+0x174/0x338\n[ 2538.461021] __schedule+0x628/0x9c4\n[ 2538.461025] schedule+0x7c/0xe8\n[ 2538.461030] blk_queue_enter+0xc4/0x160\n[ 2538.461034] blk_mq_alloc_request+0x120/0x1d4\n[ 2538.461037] scsi_execute_cmd+0x7c/0x23c\n[ 2538.461040] ioctl_internal_command+0x5c/0x164\n[ 2538.461046] scsi_set_medium_removal+0x5c/0xb0\n[ 2538.461051] sd_release+0x50/0x94\n[ 2538.461054] blkdev_put+0x190/0x28c\n[ 2538.461058] blkdev_release+0x28/0x40\n[ 2538.461063] __fput+0xf8/0x2a8\n[ 2538.461066] __fput_sync+0x28/0x5c\n[ 2538.461070] __arm64_sys_close+0x84/0xe8\n[ 2538.461073] invoke_syscall+0x58/0x114\n[ 2538.461078] el0_svc_common+0xac/0xe0\n[ 2538.461082] do_el0_svc+0x1c/0x28\n[ 2538.461087] el0_svc+0x38/0x68\n[ 2538.461090] el0t_64_sync_handler+0x68/0xbc\n[ 2538.461093] el0t_64_sync+0x1a8/0x1ac\n\n T1:\t\t\t\tT2:\n sd_remove\n del_gendisk\n __blk_mark_disk_dead\n blk_freeze_queue_start\n ++q-\u003emq_freeze_depth\n \t\t\t\tbdev_release\n \t\t\t\tmutex_lock(\u0026disk-\u003eopen_mutex)\n \t\t\t\tsd_release\n \t\t\t\tscsi_execute_cmd\n \t\t\t\tblk_queue_enter\n \t\t\t\twait_event(!q-\u003emq_freeze_depth)\n mutex_lock(\u0026disk-\u003eopen_mutex)\n\nSCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in\nthis scenario. This is a classic ABBA deadlock. To fix the deadlock,\nmake sure we don\u0027t try to acquire disk-\u003eopen_mutex after freezing\nthe queue.",
"id": "GHSA-v82j-fhf7-mwx2",
"modified": "2024-08-19T21:35:09Z",
"published": "2024-08-17T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42294"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5a5625a83eac91fdff1d5f0202ecfc45a31983c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7e04da2dc7013af50ed3a2beb698d5168d1e594b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5418f48a93b69ed9e6a2281eee06b412f14a544"
}
],
"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-V8PP-R8HM-GFQW
Vulnerability from github – Published: 2024-05-20 12:30 – Updated: 2024-10-29 21:30In the Linux kernel, the following vulnerability has been resolved:
smb3: missing lock when picking channel
Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index.
Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")
{
"affected": [],
"aliases": [
"CVE-2024-35999"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-20T10:15:14Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: missing lock when picking channel\n\nCoverity spotted a place where we should have been holding the\nchannel lock when accessing the ses channel index.\n\nAddresses-Coverity: 1582039 (\"Data race condition (MISSING_LOCK)\")",
"id": "GHSA-v8pp-r8hm-gfqw",
"modified": "2024-10-29T21:30:47Z",
"published": "2024-05-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35999"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729"
}
],
"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-V8QX-G69V-PPH9
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-07-14 21:31In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: fix deadlock in hid_post_reset()
You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.
{
"affected": [],
"aliases": [
"CVE-2026-53037"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:15Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: usbhid: fix deadlock in hid_post_reset()\n\nYou can build a USB device that includes a HID component\nand a storage or UAS component. The components can be reset\nonly together. That means that hid_pre_reset() and hid_post_reset()\nare in the block IO error handling. Hence no memory allocation\nused in them may do block IO because the IO can deadlock\non the mutex held while resetting a device and calling the\ninterface drivers.\nUse GFP_NOIO for all allocations in them.",
"id": "GHSA-v8qx-g69v-pph9",
"modified": "2026-07-14T21:31:29Z",
"published": "2026-06-24T18:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53037"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e900465296ce9fb12ed47dc77389b8dde95bfe0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56d318ef8766f0deb08517fd8f3007256ea7997d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90550af0aad5e75110073c501e4fb42fca20ff80"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ad4505d2ab3aaac6498f17649608e70e80034bf2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b3d16611d7cd78e9d5c6baa19b61b7caf9f1ab5e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7abd0e6c87441e99c759d40eb6fe589634e3041"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eeceb6f4dd42065fdda3a526a93d08b8fb90fb69"
}
],
"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-V97Q-699F-9M4X
Vulnerability from github – Published: 2026-02-02 09:30 – Updated: 2026-02-03 00:30In imgsys, there is a possible memory corruption due to improper locking. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10363254; Issue ID: MSV-5617.
{
"affected": [],
"aliases": [
"CVE-2026-20415"
],
"database_specific": {
"cwe_ids": [
"CWE-415",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-02T09:15:56Z",
"severity": "MODERATE"
},
"details": "In imgsys, there is a possible memory corruption due to improper locking. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10363254; Issue ID: MSV-5617.",
"id": "GHSA-v97q-699f-9m4x",
"modified": "2026-02-03T00:30:18Z",
"published": "2026-02-02T09:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20415"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/February-2026"
}
],
"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-VC6H-6PQG-P2HX
Vulnerability from github – Published: 2024-06-08 15:31 – Updated: 2025-02-03 18:30In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: Use request_module_nowait
This appears to work around a deadlock regression that came in with the LED merge in 6.9.
The deadlock happens on my system with 24 iwlwifi radios, so maybe it something like all worker threads are busy and some work that needs to complete cannot complete.
[also remove unnecessary "load_module" var and now-wrong comment]
{
"affected": [],
"aliases": [
"CVE-2024-36970"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-08T13:15:58Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: Use request_module_nowait\n\nThis appears to work around a deadlock regression that came in\nwith the LED merge in 6.9.\n\nThe deadlock happens on my system with 24 iwlwifi radios, so maybe\nit something like all worker threads are busy and some work that needs\nto complete cannot complete.\n\n[also remove unnecessary \"load_module\" var and now-wrong comment]",
"id": "GHSA-vc6h-6pqg-p2hx",
"modified": "2025-02-03T18:30:37Z",
"published": "2024-06-08T15:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36970"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d913719df14c28c4d3819e7e6d150760222bda4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d20013259539e2fde2deeac85354851097afdf9e"
}
],
"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-VCR5-6JVW-92H4
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
net: switchdev: Convert blocking notification chain to a raw one
A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event.
In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1].
Specifically, this can happen when the bridge driver processes a SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdev_deferred_process().
Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in call_switchdev_blocking_notifiers() to make sure this is not violated in the future.
Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block.
[1]: WARNING: possible recursive locking detected 6.14.0-rc4-custom-g079270089484 #1 Not tainted
ip/52731 is trying to acquire lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0
but task is already holding lock: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0
other info that might help us debug this: Possible unsafe locking scenario: CPU0
lock((switchdev_blocking_notif_chain).rwsem); lock((switchdev_blocking_notif_chain).rwsem);
*** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by ip/52731: #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0 #1: ffffffff8731f628 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0 #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0
stack backtrace: ... ? __pfx_down_read+0x10/0x10 ? __pfx_mark_lock+0x10/0x10 ? __pfx_switchdev_port_attr_set_deferred+0x10/0x10 blocking_notifier_call_chain+0x58/0xa0 switchdev_port_attr_notify.constprop.0+0xb3/0x1b0 ? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10 ? mark_held_locks+0x94/0xe0 ? switchdev_deferred_process+0x11a/0x340 switchdev_port_attr_set_deferred+0x27/0xd0 switchdev_deferred_process+0x164/0x340 br_switchdev_port_unoffload+0xc8/0x100 [bridge] br_switchdev_blocking_event+0x29f/0x580 [bridge] notifier_call_chain+0xa2/0x440 blocking_notifier_call_chain+0x6e/0xa0 switchdev_bridge_port_unoffload+0xde/0x1a0 ...
{
"affected": [],
"aliases": [
"CVE-2025-21986"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: switchdev: Convert blocking notification chain to a raw one\n\nA blocking notification chain uses a read-write semaphore to protect the\nintegrity of the chain. The semaphore is acquired for writing when\nadding / removing notifiers to / from the chain and acquired for reading\nwhen traversing the chain and informing notifiers about an event.\n\nIn case of the blocking switchdev notification chain, recursive\nnotifications are possible which leads to the semaphore being acquired\ntwice for reading and to lockdep warnings being generated [1].\n\nSpecifically, this can happen when the bridge driver processes a\nSWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications\nabout deferred events when calling switchdev_deferred_process().\n\nFix this by converting the notification chain to a raw notification\nchain in a similar fashion to the netdev notification chain. Protect\nthe chain using the RTNL mutex by acquiring it when modifying the chain.\nEvents are always informed under the RTNL mutex, but add an assertion in\ncall_switchdev_blocking_notifiers() to make sure this is not violated in\nthe future.\n\nMaintain the \"blocking\" prefix as events are always emitted from process\ncontext and listeners are allowed to block.\n\n[1]:\nWARNING: possible recursive locking detected\n6.14.0-rc4-custom-g079270089484 #1 Not tainted\n--------------------------------------------\nip/52731 is trying to acquire lock:\nffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nbut task is already holding lock:\nffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\nCPU0\n----\nlock((switchdev_blocking_notif_chain).rwsem);\nlock((switchdev_blocking_notif_chain).rwsem);\n\n*** DEADLOCK ***\nMay be due to missing lock nesting notation\n3 locks held by ip/52731:\n #0: ffffffff84f795b0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x727/0x1dc0\n #1: ffffffff8731f628 (\u0026net-\u003ertnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x790/0x1dc0\n #2: ffffffff850918d8 ((switchdev_blocking_notif_chain).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain+0x58/0xa0\n\nstack backtrace:\n...\n? __pfx_down_read+0x10/0x10\n? __pfx_mark_lock+0x10/0x10\n? __pfx_switchdev_port_attr_set_deferred+0x10/0x10\nblocking_notifier_call_chain+0x58/0xa0\nswitchdev_port_attr_notify.constprop.0+0xb3/0x1b0\n? __pfx_switchdev_port_attr_notify.constprop.0+0x10/0x10\n? mark_held_locks+0x94/0xe0\n? switchdev_deferred_process+0x11a/0x340\nswitchdev_port_attr_set_deferred+0x27/0xd0\nswitchdev_deferred_process+0x164/0x340\nbr_switchdev_port_unoffload+0xc8/0x100 [bridge]\nbr_switchdev_blocking_event+0x29f/0x580 [bridge]\nnotifier_call_chain+0xa2/0x440\nblocking_notifier_call_chain+0x6e/0xa0\nswitchdev_bridge_port_unoffload+0xde/0x1a0\n...",
"id": "GHSA-vcr5-6jvw-92h4",
"modified": "2025-11-03T21:33:27Z",
"published": "2025-04-01T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21986"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f7d051814e7a0cb1f0717ed5527c1059992129d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62531a1effa87bdab12d5104015af72e60d926ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a597d4b75669ec82c72cbee9fe75a15d04b35b2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/af757f5ee3f754c5dceefb05c12ff37cb46fc682"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9ed3fb50b872bd78bcb01f25087f9e4e25085d8"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-VF44-3G39-FV4R
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-12-23 15:30In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.
[..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....]
Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.
{
"affected": [],
"aliases": [
"CVE-2024-27010"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix mirred deadlock on device recursion\n\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\n\n[..... other info removed for brevity....]\n[ 82.890906]\n[ 82.890906] ============================================\n[ 82.890906] WARNING: possible recursive locking detected\n[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W\n[ 82.890906] --------------------------------------------\n[ 82.890906] ping/418 is trying to acquire lock:\n[ 82.890906] ffff888006994110 (\u0026sch-\u003eq.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] but task is already holding lock:\n[ 82.890906] ffff888006994110 (\u0026sch-\u003eq.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] other info that might help us debug this:\n[ 82.890906] Possible unsafe locking scenario:\n[ 82.890906]\n[ 82.890906] CPU0\n[ 82.890906] ----\n[ 82.890906] lock(\u0026sch-\u003eq.lock);\n[ 82.890906] lock(\u0026sch-\u003eq.lock);\n[ 82.890906]\n[ 82.890906] *** DEADLOCK ***\n[ 82.890906]\n[..... other info removed for brevity....]\n\nExample setup (eth0-\u003eeth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\n\nAnother example(eth0-\u003eeth1-\u003eeth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth1\n\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\n\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.",
"id": "GHSA-vf44-3g39-fv4r",
"modified": "2024-12-23T15:30:46Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27010"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef"
},
{
"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-VFPR-G7CV-3QW9
Vulnerability from github – Published: 2022-04-30 18:22 – Updated: 2024-02-09 00:31mod_cgi in Apache 2.0.39 and 2.0.40 allows local users and possibly remote attackers to cause a denial of service (hang and memory consumption) by causing a CGI script to send a large amount of data to stderr, which results in a read/write deadlock between httpd and the CGI script.
{
"affected": [],
"aliases": [
"CVE-2002-1850"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2002-12-31T05:00:00Z",
"severity": "MODERATE"
},
"details": "mod_cgi in Apache 2.0.39 and 2.0.40 allows local users and possibly remote attackers to cause a denial of service (hang and memory consumption) by causing a CGI script to send a large amount of data to stderr, which results in a read/write deadlock between httpd and the CGI script.",
"id": "GHSA-vfpr-g7cv-3qw9",
"modified": "2024-02-09T00:31:31Z",
"published": "2022-04-30T18:22:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2002-1850"
},
{
"type": "WEB",
"url": "http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/generators/mod_cgi.c?r1=1.148.2.7\u0026r2=1.148.2.8"
},
{
"type": "WEB",
"url": "http://issues.apache.org/bugzilla/show_bug.cgi?id=10515"
},
{
"type": "WEB",
"url": "http://issues.apache.org/bugzilla/show_bug.cgi?id=22030"
},
{
"type": "WEB",
"url": "http://marc.info/?l=apache-httpd-dev\u0026m=103291952019514\u0026w=2"
},
{
"type": "WEB",
"url": "http://seclists.org/bugtraq/2002/Sep/0253.html"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1007823"
},
{
"type": "WEB",
"url": "http://www.iss.net/security_center/static/10200.php"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/5787"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/8725"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VG65-JQ85-8Q85
Vulnerability from github – Published: 2026-06-26 21:32 – Updated: 2026-07-06 21:30In the Linux kernel, the following vulnerability has been resolved:
net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops
DSA replaces the conduit (master) device's ethtool_ops with its own wrappers that aggregate stats from both the conduit and DSA switch ports. Taking the lock again inside the DSA wrappers causes a deadlock.
Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y
(which looks like some kind of testing device that auto-populates the ports
of eth0). ethtool -i is enough to deadlock. This means we have basically zero
coverage for DSA stuff with real ops locked devs.
Remove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from the DSA conduit ethtool wrappers.
{
"affected": [],
"aliases": [
"CVE-2026-53323"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T20:17:25Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops\n\nDSA replaces the conduit (master) device\u0027s ethtool_ops with its own\nwrappers that aggregate stats from both the conduit and DSA switch\nports. Taking the lock again inside the DSA wrappers causes a deadlock.\n\nStumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y\n(which looks like some kind of testing device that auto-populates the ports\nof eth0). `ethtool -i` is enough to deadlock. This means we have basically zero\ncoverage for DSA stuff with real ops locked devs.\n\nRemove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from\nthe DSA conduit ethtool wrappers.",
"id": "GHSA-vg65-jq85-8q85",
"modified": "2026-07-06T21:30:26Z",
"published": "2026-06-26T21:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53323"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f99e0c3e19badaf3fdced0d3feba623e59eed41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/74d64ae4254e99ef8c8215b057a76edac82c5f99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/abe91fd045874d21834482adcd7a9693e7377056"
}
],
"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-VH5C-FH26-4H3R
Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-03 18:55In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled
When I did hard offline test with hugetlb pages, below deadlock occurs:
====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted
bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60
but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30
-> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock);
*** DEADLOCK ***
5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40
stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00
In short, below scene breaks the ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26987"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T06:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled\n\nWhen I did hard offline test with hugetlb pages, below deadlock occurs:\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.8.0-11409-gf6cef5f8c37f #1 Not tainted\n------------------------------------------------------\nbash/46904 is trying to acquire lock:\nffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60\n\nbut task is already holding lock:\nffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u003e #1 (pcp_batch_high_lock){+.+.}-{3:3}:\n __mutex_lock+0x6c/0x770\n page_alloc_cpu_online+0x3c/0x70\n cpuhp_invoke_callback+0x397/0x5f0\n __cpuhp_invoke_callback_range+0x71/0xe0\n _cpu_up+0xeb/0x210\n cpu_up+0x91/0xe0\n cpuhp_bringup_mask+0x49/0xb0\n bringup_nonboot_cpus+0xb7/0xe0\n smp_init+0x25/0xa0\n kernel_init_freeable+0x15f/0x3e0\n kernel_init+0x15/0x1b0\n ret_from_fork+0x2f/0x50\n ret_from_fork_asm+0x1a/0x30\n\n-\u003e #0 (cpu_hotplug_lock){++++}-{0:0}:\n __lock_acquire+0x1298/0x1cd0\n lock_acquire+0xc0/0x2b0\n cpus_read_lock+0x2a/0xc0\n static_key_slow_dec+0x16/0x60\n __hugetlb_vmemmap_restore_folio+0x1b9/0x200\n dissolve_free_huge_page+0x211/0x260\n __page_handle_poison+0x45/0xc0\n memory_failure+0x65e/0xc70\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x387/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xca/0x1e0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(pcp_batch_high_lock);\n lock(cpu_hotplug_lock);\n lock(pcp_batch_high_lock);\n rlock(cpu_hotplug_lock);\n\n *** DEADLOCK ***\n\n5 locks held by bash/46904:\n #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0\n #1: ffff98f6c328e488 (\u0026of-\u003emutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0\n #2: ffff98ef83b31890 (kn-\u003eactive#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0\n #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70\n #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40\n\nstack backtrace:\nCPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x68/0xa0\n check_noncircular+0x129/0x140\n __lock_acquire+0x1298/0x1cd0\n lock_acquire+0xc0/0x2b0\n cpus_read_lock+0x2a/0xc0\n static_key_slow_dec+0x16/0x60\n __hugetlb_vmemmap_restore_folio+0x1b9/0x200\n dissolve_free_huge_page+0x211/0x260\n __page_handle_poison+0x45/0xc0\n memory_failure+0x65e/0xc70\n hard_offline_page_store+0x55/0xa0\n kernfs_fop_write_iter+0x12c/0x1d0\n vfs_write+0x387/0x550\n ksys_write+0x64/0xe0\n do_syscall_64+0xca/0x1e0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fc862314887\nCode: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24\nRSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887\nRDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001\nRBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c\nR13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00\n\nIn short, below scene breaks the \n---truncated---",
"id": "GHSA-vh5c-fh26-4h3r",
"modified": "2024-06-03T18:55:51Z",
"published": "2024-05-01T06:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26987"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1983184c22dd84a4d95a71e5c6775c2638557dc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49955b24002dc16a0ae2e83a57a2a6c863a1845c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5ef7ba2799a3b5ed292b8f6407376e2c25ef002e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/882e1180c83f5b75bae03d0ccc31ccedfe5159de"
},
{
"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"
}
]
}
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.