CVE-2026-64103: scsi: isci: Fix use-after-free in device removal path
In the Linux kernel, the following vulnerability has been resolved:
scsi: isci: Fix use-after-free in device removal path
The ISCI completion tasklet is initialized in iscihostalloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613).
iscihostdeinit() stops the controller and waits for stop completion, but it never kills completiontasklet before teardown continues. A top-of-function taskletkill() is not sufficient here: interrupts are only disabled when iscihoststopcomplete() runs, so until waitforstop() returns the IRQ handlers can still requeue the tasklet. The tasklet callback also re-enables interrupts after draining completions, so killing the tasklet before the source is quiesced leaves the same race open.
Once waitforstop() returns, no further IRQ-driven scheduling can occur. Kill completiontasklet there so teardown cannot race a queued tasklet running on a dead ihost. On remove or unload, the stale callback can otherwise dereference ihost and touch ihost->smuregisters after the host lifetime ends.
A UML + KASAN analogue reproduced the failure class both with no taskletkill() and with taskletkill() placed before source quiesce, and stayed clean once the kill happened after quiescing the scheduling source.
This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in device removal path"), but ISCI needs the kill after waitforstop().
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel ISCI SCSI driver are exposed during device removal or driver unload. The vulnerable path involves the driver's completion tasklet and interrupt handling during teardown.
What conditions are required to trigger the flaw?
An attacker needs local access and low privileges, as reflected by the CVSS vector. The issue is triggered when a queued or requeued ISCI completion tasklet runs after the ISCI host object has been torn down.
Is this a remotely exploitable issue?
The provided CVSS vector lists local attack access (AV:L). No remote attack path is described.
What is the impact if exploitation succeeds?
The stale tasklet can dereference the freed ISCI host structure and access its SMU registers after host lifetime ends. The supplied CVSS metrics indicate high confidentiality, integrity, and availability impact.
What mitigates the issue when immediate patching is not possible?
The described exposure occurs on ISCI device removal or driver unload. Avoiding those teardown operations for affected ISCI hosts reduces exposure until a kernel containing the fix can be deployed.