CVE-2026-43413

What it actually does

This is a local denial-of-service flaw in the Linux kernel SCSI SAS handling path for systems using the hisi_sas driver. A user-triggered SCSI rescan can cause the kernel to scan a non-existent secondary channel on hardware that supports only one channel, leading to a NULL pointer dereference in sas_find_dev_by_rphy(). The result is a kernel oops and potential system crash, hang, or degraded storage availability. The issue does not provide confidentiality or integrity impact by itself; the primary impact is availability loss.

Why it matters to the business

Affected Linux systems with HiSilicon SAS storage controllers can be disrupted by a local user or process that can trigger SCSI host scans, potentially causing outages for workloads that depend on those hosts or attached storage. Because the flaw affects kernel availability, exploitation can interrupt applications, databases, virtualization hosts, or storage services running on affected hardware. The CVSS score is moderate, EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is indicated, so broad internet-scale exploitation is unlikely; however, the operational impact can still be high on exposed multi-user or administration-heavy systems.

How an attack unfolds

An attacker first obtains local access to an affected Linux system using the hisi_sas driver. They then identify a SCSI host backed by the vulnerable SAS driver and invoke a user-controlled SCSI scan through the sysfs SCSI host scan interface. The kernel processes the request through store_scan(), sas_user_scan(), and scsi_scan_host_selected(). Because the driver advertises or exposes channel handling inconsistent with the hardware capability, the scan path attempts to operate on channel 1 even though the controller supports only one channel. This reaches sas_find_dev_by_rphy() with an unexpected NULL object and triggers a NULL pointer dereference. Depending on kernel panic settings and system resilience, this can produce a kernel oops, crash the host, or leave storage-related services impaired until recovery or reboot.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the hisi_sas user_scan() NULL pointer dereference. Because no fixed package versions were provided, use the corrected kernel versions from the operating system, distribution, appliance, or hardware vendor that supplies the affected kernel. Prioritize systems where the hisi_sas or hisi_sas_v3_hw modules are loaded, especially production storage, virtualization, database, and multi-user hosts. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting sudo or administrative workflows that can write to SCSI sysfs scan files, monitoring and controlling writes to /sys/class/scsi_host/host*/scan, and removing or disabling unused hisi_sas hardware/drivers where operationally safe. Kernel live patching may be suitable if the vendor provides coverage for this specific fix; otherwise schedule a reboot into a fixed kernel.

How to confirm the fix worked

Confirm whether the system is exposed by checking for the vulnerable hardware/driver path: verify whether hisi_sas_main or hisi_sas_v3_hw is loaded, whether HiSilicon SAS controllers are present, and whether the running kernel build contains the vendor backport for this fix. Validate remediation by booting into the vendor-fixed kernel and confirming the vulnerable modules are updated or the patch is present in the kernel changelog/source package. Review /proc/modules, lsmod output, modinfo output, distribution package metadata, and kernel release notes. On non-production test systems only, a controlled SCSI rescan can be used to confirm the kernel no longer oopses; do not perform crash-validation on production hosts.

Typical attack path

1. Gain local access to an affected Linux host where the hisi_sas kernel driver is loaded.
2. Confirm the presence of SCSI hosts associated with HiSilicon SAS hardware.
3. Trigger a user-initiated SCSI rescan through the sysfs SCSI host scan interface.
4. Cause the kernel to scan an unsupported channel for the hisi_sas controller.
5. Trigger a NULL pointer dereference in the SAS/SCSI scan path.
6. Cause a kernel oops, system instability, host crash, or storage service disruption.

How to detect it

To determine whether this flaw was already triggered, review kernel logs, persistent journal logs, crash dump records, and centralized syslog/SIEM data for kernel oops or panic events involving the SCSI/SAS scan path. Relevant log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore, kdump/vmcore records, crash directories, auditd logs, sudo logs, shell history, and EDR process/file telemetry. Look for writes to /sys/class/scsi_host/host*/scan followed closely by kernel messages showing NULL pointer dereference, Internal error: Oops, sas_find_dev_by_rphy, sas_target_alloc, scsi_scan_host_selected, sas_user_scan, store_scan, and loaded modules such as hisi_sas_main or hisi_sas_v3_hw. A strong indication of exploitation or accidental triggering is a local process writing to the SCSI scan sysfs file shortly before a kernel oops with the described call trace. Distinguish malicious activity from legitimate storage administration by correlating with change tickets, maintenance windows, administrator sessions, package updates, multipath/storage rescans, and hardware events.

• Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0
• Internal error: Oops: 0000000096000004
• sas_find_dev_by_rphy+0x44/0x118
• sas_target_alloc+0x24/0xb0
• scsi_alloc_target+0x290/0x330
• __scsi_scan_target+0x88/0x258
• scsi_scan_channel+0x74/0xb8
• scsi_scan_host_selected+0x170/0x188
• sas_user_scan+0xfc/0x148
• store_scan+0x10c/0x180
• dev_attr_store+0x20/0x40
• sysfs_kf_write+0x84/0xa8
• kernfs_fop_write_iter+0x130/0x1c8
• /sys/class/scsi_host/host*/scan
• hisi_sas_v3_hw
• hisi_sas_main
• Modules linked in: arm_spe_pmu
• Comm: bash Kdump: loaded
• ESR = 0x0000000096000004
• FSC = 0x04: level 0 translation fault

What your security team should do

• Inventory Linux systems using HiSilicon SAS controllers or loaded hisi_sas/hisi_sas_v3_hw modules.
• Prioritize patching for production systems where storage availability is business-critical or where multiple administrators/users have local access.
• Update to a vendor-fixed kernel and reboot, or apply an approved live patch if available.
• Until patched, restrict local access and tightly control permissions or sudo rules that allow writes to /sys/class/scsi_host/host*/scan.
• Add monitoring for kernel oops signatures involving sas_find_dev_by_rphy, sas_user_scan, scsi_scan_host_selected, and hisi_sas modules.
• Review recent kernel logs for evidence of prior crashes or oops events matching this call trace.
• Ensure crash dump collection, watchdog behavior, and service failover are functioning for affected storage hosts.