CVE-2026-80653

What it actually does

Race condition in hisi_sas v3 device link handling during concurrent remote PHY link reset and driver unload allows __device_links_no_driver to be invoked on a still-bound link state, triggering a kernel WARNING in the device core during SAS target removal and workqueue flush.

Why it matters to the business

On systems using Hisilicon SAS controllers, simultaneous link management operations and driver removal can produce kernel warnings that destabilize storage paths, interrupt I/O, and require reboots, increasing downtime for storage-heavy workloads.

How an attack unfolds

An attacker with local access issues repeated link resets on a remote SAS PHY while simultaneously unloading the SAS driver module; the resulting race leaves a device link in DL_STATE_AVAILABLE during cleanup, causing the documented WARNING path through sas_rphy_delete and device_release_driver.

How to fix it

Update the Linux kernel to a version containing the slave_destroy interface addition for hisi_sas v3 hardware; ensure the fix that flushes workqueues before link removal is present. Where immediate patching is not possible, avoid concurrent link-reset and driver-unload operations.

How to confirm the fix worked

Confirm the presence of the slave_destroy callback in the hisi_sas driver and verify that the WARNING at drivers/base/core.c:1347 no longer occurs under concurrent reset+rmmod workloads; inspect dmesg and kernel logs after targeted stress tests.

Typical attack path

1. Obtain local shell or script execution on the target host
2. Trigger SAS PHY link resets via sysfs or management tools
3. Concurrently invoke rmmod on the hisi_sas or libsas module
4. Observe kernel WARNING and potential follow-on instability in SCSI device removal

How to detect it

Search kernel logs and dmesg for the exact WARNING string referencing __device_links_no_driver combined with call traces containing sas_rphy_delete, sas_destruct_devices, or device_release_driver around the time of module unload or SAS domain revalidation events.

• WARNING: CPU:.*at drivers/base/core.c:1347 __device_links_no_driver
• Call trace.*device_links_driver_cleanup.*__device_release_driver.*sas_rphy_delete

What your security team should do

• Prioritize kernel updates on all hosts exposing Hisilicon SAS controllers
• Add monitoring for the specific WARNING signature in kernel logs
• Restrict unprivileged local access to storage management interfaces until patched
• Document and avoid scripted concurrent reset/unload sequences in operational runbooks