CVE-2026-80653 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Add slave_destroy interface for v3 hw
WARNING is triggered when executing link reset of remote PHY and rmmod SAS driver simultaneously. Following is the WARNING log:
WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0 Call trace: __device_links_no_driver+0xb4/0xc0 device_links_driver_cleanup+0xb0/0xfc __device_release_driver+0x198/0x23c device_release_driver+0x38/0x50 bus_remove_device+0x130/0x140 device_del+0x184/0x434 __scsi_remove_device+0x118/0x150 scsi_remove_target+0x1bc/0x240 sas_rphy_remove+0x90/0x94 sas_rphy_delete+0x24/0x3c sas_destruct_devices+0x64/0xa0 [libsas]
sas_revalidate_domain+0xe4/0x150 [libsas]
process_one_work+0x1e0/0x46c worker_thread+0x15c/0x464 kthread+0x160/0x170 ret_from_fork+0x10/0x20 ---[ end trace 71e059eb58f85d4a ]---
During SAS phy up, link->status is set to DL_STATE_AVAILABLE in device_links_driver_bound, then this setting influences __device_links_no_driver() before driver rmmod and caused WARNING.
Add the slave_destroy interface to make sure link is removed after flush workque.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel vulnerability identified within the hisi_sas SCSI host adapter driver involves a race condition during device removal that triggers a kernel warning related to improper device link management. This issue specifically affects hardware version 3 of the HiSilicon SAS controllers and manifests when an administrator attempts to remove the SAS driver module while a remote PHY link reset operation is concurrently in progress. The core technical flaw lies in the timing of state transitions for the SAS physical layer links relative to the kernel's device model cleanup procedures. When the SAS phy initialization completes, the link status is updated to DL_STATE_AVAILABLE within the device_links_driver_bound function. This update signals that the driver has successfully bound to the device and established valid hardware connections. However, if the rmmod command is executed immediately after this binding but before subsequent asynchronous work items have fully completed their lifecycle, the kernel's device cleanup logic detects a discrepancy in the expected state of the device links.
The operational impact of this vulnerability is primarily observed as a disruptive WARNING message logged to the system console, indicating that __device_links_no_driver was invoked on a device that still appears to be bound or improperly unlinked. The call trace reveals that the warning originates from the core kernel subsystem responsible for managing dependencies between devices and drivers during driver removal. Specifically, the sequence involves scsi_remove_device calling sas_rphy_delete, which triggers sas_destruct_devices. This function attempts to clean up SAS remote PHY objects but encounters a state where device links are not in the expected unbound condition because the asynchronous work queue processing has not yet finalized the teardown of the link status. While this does not typically result in immediate data corruption or system crash, it indicates a violation of kernel synchronization protocols and can lead to unstable behavior if the race window is exploited repeatedly or under heavy I/O load conditions that prolong the duration of these concurrent operations.
From a vulnerability classification perspective, this issue aligns with CWE-362, which describes Concurrent Execution using Shared Resource with Improper Synchronization Race Conditions. The root cause is not an arbitrary memory corruption but rather a logical race condition where the driver fails to properly synchronize its internal state machine with the kernel's device lifecycle events. In terms of the MITRE ATT&CK framework for Linux systems, this relates to techniques involving improper resource cleanup and potential denial of service through log flooding or system instability, although it is primarily categorized as a stability defect rather than an exploitable security flaw in most contexts. The vulnerability highlights gaps in how hardware-specific drivers handle asynchronous work queues during driver unloading phases, particularly when the hardware requires explicit teardown steps that must complete before the kernel considers the device fully detached from its driver.
The resolution implemented by adding the slave_destroy interface ensures that the SAS link removal is properly sequenced after flushing all pending work queue items. This change enforces a strict ordering where asynchronous tasks related to PHY status and domain validation are guaranteed to finish their execution before the driver proceeds with final cleanup steps in device_links_driver_cleanup. By introducing this synchronization point, the kernel prevents the __device_links_no_driver warning from being triggered by stale state references. Mitigation for system administrators involves ensuring that drivers are not unloaded during active link reset operations or heavy I/O periods where PHY status changes are frequent. For long-term stability, applying the patched version of the hisi_sas driver is essential to maintain proper adherence to kernel device model standards and prevent potential instability in storage subsystems relying on HiSilicon hardware controllers.