CVE-2023-54100 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
scsi: qedi: Fix use after free bug in qedi_remove()
In qedi_probe() we call __qedi_probe() which initializes &qedi->recovery_work with qedi_recovery_handler() and &qedi->board_disable_work with qedi_board_disable_work().
When qedi_schedule_recovery_handler() is called, schedule_delayed_work() will finally start the work.
In qedi_remove(), which is called to remove the driver, the following sequence may be observed:
Fix this by finishing the work before cleanup in qedi_remove().
CPU0 CPU1
|qedi_recovery_handler qedi_remove | __qedi_remove | iscsi_host_free | scsi_host_put | //free shost | |iscsi_host_for_each_session |//use qedi->shost
Cancel recovery_work and board_disable_work in __qedi_remove().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/03/2026
The vulnerability identified as CVE-2023-54100 represents a critical use-after-free condition within the Linux kernel's SCSI QEDi driver implementation. This flaw exists in the qedi_remove() function where improper cleanup sequencing leads to memory access violations. The issue stems from the driver's handling of delayed work structures that are scheduled during the probe phase but not properly terminated before resource deallocation occurs. The vulnerability manifests when the driver's removal process fails to adequately cancel pending work items before freeing associated memory structures, creating a window where freed memory can still be accessed by ongoing work handlers.
The technical root cause of this vulnerability aligns with CWE-416, which describes the use of freed memory condition. The qedi driver initializes two key work structures during probe operations: recovery_work and board_disable_work, both of which are scheduled to execute asynchronously. The problem occurs when qedi_remove() is invoked to unload the driver, but the cleanup sequence does not properly terminate these scheduled works before the underlying SCSI host structure gets freed. This creates a race condition where work items that reference freed memory structures can still execute, leading to potential system crashes or arbitrary code execution.
The operational impact of this vulnerability is significant within systems that utilize QEDi SCSI drivers, particularly in enterprise storage environments where driver unloading operations are common. Attackers could potentially exploit this condition to cause system instability through denial of service or to execute arbitrary code with kernel privileges. The vulnerability is particularly concerning because it operates at the kernel level where memory corruption can lead to complete system compromise. The timing of the flaw makes it especially dangerous as it occurs during driver removal, a common operation that might be triggered by system updates, hardware changes, or normal system maintenance procedures.
Mitigation strategies for this vulnerability require immediate patch application from kernel maintainers, as the fix involves proper work cancellation before resource cleanup. The recommended solution implements explicit cancellation of both recovery_work and board_disable_work structures within the __qedi_remove() function before proceeding with the standard cleanup operations. This approach follows established best practices for kernel driver development and aligns with ATT&CK technique T1059.006 for kernel exploitation prevention. System administrators should prioritize patching affected kernel versions and monitoring for potential exploitation attempts. The vulnerability also highlights the importance of proper resource management in kernel modules and demonstrates the critical need for thorough testing of driver removal sequences to prevent similar use-after-free conditions in other kernel subsystems.