CVE intelligence

CVE-2026-64103

Vulnerability intelligence

Published Jul 19, 2026Sources checked Oct 27, 2026

7.8HIGHCVSS out of 10

What this means

Review the available evidence

CVE-2026-64103 and is rated High severity with a CVSS score of 7.8. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Ubuntu Security Notices guidance

Vendor revision: Sep 29, 2026

Vendor remediation details

This update corrects flaws in the following subsystems: - ARM32 architecture; - ARM64 architecture; - PowerPC architecture; - Compute Acceleration Framework; - Drivers core; - Bluetooth drivers; - Arm Firmware Framework for ARMv8-A(FFA); - EFI core; - GPU drivers; - Hardware monitoring drivers; - InfiniBand drivers; - Network drivers; - Microsoft Azure Network Adapter (MANA) driver; - SCSI subsystem; - SPI subsystem; - Network file systems library; - NTFS3 file system; - SMB network file system; - File systems infrastructure; - Software nodes and device properties; - Bluetooth subsystem; - Netfilter; - Tracing infrastructure; - io_uring subsystem; - IRQ subsystem; - KProbes tracing; - Memory management; - B.A.T.M.A.N.

Ubuntu Security Notices guidance

Vendor revision: Sep 25, 2026

Vendor remediation details

Ubuntu Security Notices guidance

Vendor revision: Sep 22, 2026

Vendor remediation details

CISA KEVNot listedBased on the latest collected catalog

EPSS0.1%Estimated 30-day exploitation probability

Ransomware useNot markedCISA KEV ransomware field

Threat actors0Source-linked actor relationships

Overview

What is CVE-2026-64103?

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().

Source: NVD