CVE-2024-42294 in Linux
Summary
by MITRE • 08/17/2024
In 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 01/16/2026
The vulnerability described in CVE-2024-42294 represents a critical deadlock condition within the Linux kernel's block layer, specifically affecting SCSI device handling mechanisms. This issue manifests as a hung task scenario where system threads become indefinitely blocked, leading to potential system unresponsiveness and denial of service conditions. The deadlock occurs during the removal and release of SCSI devices, particularly when the kernel attempts to manage the lifecycle of storage devices connected via USB or other SCSI-based interfaces.
The technical root cause of this vulnerability lies in the improper ordering of mutex acquisition and queue freezing operations within the kernel's block subsystem. The deadlock pattern follows a classic ABBA deadlock scenario where two threads contend for resources in opposing orders. Thread one attempts to acquire the disk's open_mutex after calling blk_freeze_queue_start, while thread two attempts to acquire the same mutex after calling blk_queue_enter, which waits on the queue's freeze state. This circular dependency creates an indefinite blocking condition that prevents both threads from proceeding, effectively freezing the system's ability to process I/O operations for the affected storage devices.
The vulnerability affects the Linux kernel's SCSI subsystem, particularly the sd (SCSI disk) driver implementation, where the device removal process encounters a race condition between the sd_remove and sd_release functions. The call traces reveal that the deadlock occurs during device disconnection, specifically when the kernel attempts to remove a SCSI device from the system while another thread holds a lock on the device's open_mutex. This scenario typically arises during hotplug operations or when devices are disconnected, particularly USB storage devices that rely on SCSI command interfaces.
The operational impact of this vulnerability is significant, as it can cause complete system hangs or unresponsiveness when SCSI devices are removed or disconnected. The deadlock affects the kernel's ability to properly manage device lifecycle events, potentially leading to system crashes or requiring manual intervention to recover. The affected kernel versions include those where the block layer's queue management and device removal mechanisms have not been properly synchronized to prevent this specific deadlock condition. The vulnerability is particularly concerning in production environments where storage device hotplugging is common, as it can cause unexpected system downtime and data access interruptions.
The fix for this vulnerability addresses the fundamental ordering issue by ensuring that the kernel does not attempt to acquire the disk's open_mutex after freezing the queue. This prevents the ABBA deadlock condition by maintaining consistent lock ordering throughout the device removal process. The solution involves modifying the device removal code path to avoid the problematic mutex acquisition sequence that leads to the deadlock. This change ensures that queue freezing operations occur before any mutex acquisitions that might depend on the queue's state, preventing the circular dependency that causes the system to hang.
From a cybersecurity perspective, this vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and represents a critical flaw in kernel-level resource management that could be exploited to cause denial of service conditions. The vulnerability does not directly enable privilege escalation or information disclosure but creates a system stability risk that can be leveraged to disrupt service availability. The ATT&CK framework categorizes this under privilege escalation through system stability manipulation, as the vulnerability can be used to create system unresponsiveness that affects legitimate system operations and potentially impacts availability of critical services. Organizations should prioritize patching this vulnerability to maintain system stability and prevent potential exploitation through denial of service attacks targeting storage subsystems.