Skip to main content
VulnerabilityPublished Updated

CVE-2026-64103: Linux kernel · scsi: isci: Fix use-after-free in device removal path

Affects Linux kernelSource CVE Database V5

0
Compare

Not known to be exploited · fixed in cb9e72c50e6c81a5903f27e0b397ce8525d7539b : update Linux kernel when convenient.

Data as of 6 Nov 2026, 16:49 UTC

Severity
Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

Thin evidence

One scorer or none
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-11-06.

Patch
Available – fixed in cb9e72c50e6c81a5903f27e0b397ce8525d7539b, b52a8d52c3125ec9a93106ed816582368de34426, b9ff8631006233ba246828ac70409d2cb2da38d3 +5

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 6f231dda68080759f1aed3769896e94c73099f0f, < cb9e72c50e6c81a5903f27e0b397ce8525d7539b
Fixed in
  • cb9e72c50e6c81a5903f27e0b397ce8525d7539b
LinuxLinuxAffected
  • ≥ 6f231dda68080759f1aed3769896e94c73099f0f, < b52a8d52c3125ec9a93106ed816582368de34426
Fixed in
  • b52a8d52c3125ec9a93106ed816582368de34426
LinuxLinuxAffected
  • ≥ 6f231dda68080759f1aed3769896e94c73099f0f, < b9ff8631006233ba246828ac70409d2cb2da38d3
Fixed in
  • b9ff8631006233ba246828ac70409d2cb2da38d3
LinuxLinuxAffected
  • ≥ 6f231dda68080759f1aed3769896e94c73099f0f, < ab2266601a875982f2d2033f41e070a6d5e615e2
Fixed in
  • ab2266601a875982f2d2033f41e070a6d5e615e2
LinuxLinuxAffected
  • ≥ 6f231dda68080759f1aed3769896e94c73099f0f, < a83d3e4daba40d49324cec1c51ed261e1ea48cf1
Fixed in
  • a83d3e4daba40d49324cec1c51ed261e1ea48cf1
LinuxLinuxAffected
  • ≥ 6f231dda68080759f1aed3769896e94c73099f0f, < 1412995e10c74644b47f242aea6e4f3d4180e806
Fixed in
  • 1412995e10c74644b47f242aea6e4f3d4180e806

Description

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 isci_host_alloc() (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy interrupt handlers (drivers/scsi/isci/host.c:223,613). isci_host_deinit() stops the controller and waits for stop completion, but it never kills completion_tasklet before teardown continues. A top-of-function tasklet_kill() is not sufficient here: interrupts are only disabled when isci_host_stop_complete() runs, so until wait_for_stop() 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 wait_for_stop() returns, no further IRQ-driven scheduling can occur. Kill completion_tasklet 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->smu_registers after the host lifetime ends. A UML + KASAN analogue reproduced the failure class both with no tasklet_kill() and with tasklet_kill() 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 wait_for_stop().

References

Community reviews

Loading reviews…