CVE-2026-64103

What it actually does

This is a Linux kernel use-after-free in the ISCI SCSI/SAS driver teardown path. During controller removal or module unload, the driver can allow an interrupt-driven completion tasklet to remain queued or be requeued while the host object is being torn down. The stale tasklet can later dereference freed ISCI host state, including MMIO register pointers such as ihost->smu_registers. In practical terms, the most likely outcome is a kernel crash or system instability during device removal, driver unbind, or module unload. As with many kernel use-after-free flaws, a more capable exploit could potentially attempt privilege escalation or arbitrary kernel memory corruption, but the published details point to a narrow race in the device removal path rather than a broadly reachable remote attack surface.

Why it matters to the business

Systems using the Linux ISCI driver for Intel C600-style SAS/SATA storage controllers may crash or become unstable during controller removal, driver unload, maintenance, hardware replacement, or automated device-management workflows. The operational risk is highest for servers that depend on ISCI-attached storage, where a kernel panic can cause service interruption, failed maintenance windows, or storage availability incidents. Current exploitation signals are low: EPSS is approximately 0.18%, it is not listed in CISA KEV, it is not associated with ransomware use, and no public exploit maturity is indicated. Organizations should still remediate through normal kernel patching because kernel memory-safety bugs can become more serious if an attacker can reliably trigger the race locally.

How an attack unfolds

An attacker first needs a path to trigger ISCI device teardown, such as administrative access to unload the isci kernel module, unbind a matching PCI device from the driver, remove or reset relevant hardware, or otherwise exercise the controller removal path. While teardown is in progress, interrupt handlers can still schedule or requeue the ISCI completion tasklet until the controller stop sequence fully quiesces the interrupt source. In vulnerable kernels, teardown can continue without killing the tasklet at the correct point after stop completion. If the queued tasklet runs after the ISCI host object lifetime has ended, it dereferences freed memory and may touch freed register mappings. The expected observable result is a kernel oops, KASAN use-after-free report, panic, or storage/controller instability. Reliable exploitation beyond denial of service would require precise timing and kernel-specific memory manipulation and is not currently indicated by the available intelligence.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the ISCI fix. The corrective change kills the ISCI completion tasklet only after the stop path has quiesced the interrupt scheduling source, preventing the queued tasklet from racing with freed host state. No exact package fixed versions were provided in the input, so track vendor advisories for the specific distribution kernel stream in use. If immediate patching is not possible, reduce exposure by avoiding unnecessary ISCI driver unloads, PCI unbinds, hot-removal, or controller reset workflows on affected systems; restrict module loading/unloading to trusted administrators; and consider blacklisting or disabling the isci module only on systems that do not require the associated storage controller. Do not unload a production storage driver as a mitigation without validating storage dependencies, because the vulnerable path is itself associated with removal/unload activity.

How to confirm the fix worked

Confirm whether the host uses the affected driver by checking for the loaded isci module, ISCI-related PCI bindings, and kernel logs mentioning the ISCI driver. Validate remediation by confirming the running kernel package includes the vendor fix for this issue, or by source review showing completion_tasklet is killed after wait_for_stop()/stop completion in the ISCI host deinitialization path rather than before the interrupt source is quiesced. After patching, perform any required reboot into the fixed kernel and verify with uname/package-manager output that the active kernel is the patched build. In test environments only, exercise controlled driver bind/unbind or module load/unload workflows while monitoring dmesg for KASAN, use-after-free, tasklet, isci, or kernel oops messages. Production validation should avoid disruptive unload/removal testing for storage drivers unless performed during a planned maintenance window with rollback capability.

Typical attack path

1. Identify a Linux system using the ISCI SCSI/SAS driver or an affected Intel SAS/SATA controller.
2. Obtain sufficient local privileges or operational control to trigger driver removal, PCI unbind, controller reset, hot-remove, or module unload.
3. Trigger the ISCI teardown path while interrupts or completions can still schedule the completion tasklet.
4. Win the race where the completion tasklet remains queued or is requeued before the interrupt source is fully quiesced.
5. Cause the stale tasklet to execute after ISCI host teardown and dereference freed kernel memory.
6. Observe a kernel oops, KASAN report, panic, or broader system/storage disruption; in a more advanced scenario, attempt to shape the freed memory for privilege escalation.

How to detect it

Look for evidence of attempted or accidental triggering through kernel and system logs rather than network telemetry. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd, EDR process telemetry, and command history for privileged maintenance operations. Search for ISCI driver unloads, PCI unbind actions, rmmod/modprobe activity involving isci, kernel oops or panic events around storage maintenance, and KASAN reports showing use-after-free in ISCI teardown or tasklet code. Correlate crashes or reboots with administrative commands such as rmmod isci, modprobe -r isci, writes to /sys/bus/pci/drivers/isci/unbind, hardware hot-remove events, or automated maintenance tools. There are no known public attacker infrastructure indicators for this issue, and exploitation is expected to be local/operational rather than network-based.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• use-after-free in isci
• isci_host_deinit
• isci_host_stop_complete
• completion_tasklet
• isci_host_alloc
• ihost->smu_registers
• drivers/scsi/isci
• rmmod isci
• modprobe -r isci
• /sys/bus/pci/drivers/isci/unbind
• /sys/bus/pci/drivers/isci/bind
• kernel: isci
• Oops:
• Kernel panic
• tasklet

What your security team should do

• Inventory Linux systems for the isci kernel module and ISCI-bound PCI storage controllers; prioritize systems where the driver is loaded or storage depends on it.
• Patch affected Linux kernels through the normal vendor kernel update process and reboot into the fixed kernel.
• Treat internet exposure as low relevance, but treat local administrative abuse and maintenance-triggered outages as the primary risk scenarios.
• Restrict kernel module unload/load, PCI unbind, and low-level storage maintenance operations to trusted administrators and monitored automation only.
• Avoid nonessential hot-remove, driver unload, and controller reset workflows on unpatched systems, especially production storage hosts.
• Monitor kernel logs for ISCI teardown crashes, KASAN use-after-free reports, tasklet-related oopses, and unexpected reboots during storage maintenance.
• Because EPSS is low, KEV status is false, and no known exploit maturity is reported, prioritize based on whether ISCI is actually present and business-critical rather than applying emergency internet-facing remediation logic.