CVE-2026-64221

What it actually does

This is a Linux kernel use-after-free in the TI QSPI SPI controller driver. During device probe, if DMA setup succeeds far enough to obtain a DMA channel but a later buffer allocation fails, the driver can fall back or unwind without clearing the stale DMA channel pointer. Later driver operations, probe cleanup, device unbind, or error handling can pass that freed pointer back to the DMA engine or attempt to release it a second time. In kernel context, this can cause memory corruption, kernel panic, or potentially local privilege escalation with confidentiality, integrity, and availability impact. Exploitation is local and requires low-privileged access; it is most relevant on systems using the affected TI QSPI driver and hardware path.

Why it matters to the business

Affected Linux systems, especially embedded or appliance-style platforms using TI QSPI storage or peripherals, may be exposed to local kernel compromise or denial of service. A successful attacker could crash the device or potentially gain kernel-level control, which can disrupt operations, bypass host security controls, and compromise sensitive data. Current public exploitation signals are low: EPSS is very low, the issue is not in CISA KEV, no ransomware use is reported, and exploit maturity is listed as none. However, kernel memory corruption flaws should still be prioritized on exposed multi-user systems, production appliances, and systems where local code execution by untrusted users is possible.

How an attack unfolds

An attacker first needs local code execution or an existing low-privileged account on a system that includes and uses the vulnerable TI QSPI kernel driver. The attacker then attempts to influence driver probe, device binding/unbinding, or resource pressure so that DMA setup partially succeeds but a subsequent buffer allocation fails. Because the driver does not clear the DMA channel pointer on that failure path, later cleanup or driver operations can reuse or release a stale pointer. If the attacker can shape kernel heap state around this sequence, the stale pointer may be converted into a controlled use-after-free condition, potentially leading to kernel memory corruption and privilege escalation. A less controlled attempt may simply trigger a kernel panic or device instability. There are no known public exploit campaigns or named threat actors associated with this issue at this time.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution, vendor, or long-term stable branch that includes the TI QSPI driver fix for clearing the DMA channel pointer when post-DMA buffer allocation fails. No exact fixed package versions were provided in the input, so use vendor security advisories and kernel changelogs to identify the corrected build. Where immediate upgrade is not possible, reduce exposure by disabling or blacklisting the ti-qspi driver only if the platform does not require it, preventing untrusted users from gaining shell or code execution, restricting access to device-management interfaces that can trigger driver bind/unbind paths, limiting module loading to trusted administrators, and applying standard kernel hardening such as lockdown mode, module signature enforcement, secure boot, and least-privilege local access controls. Do not disable the driver on systems that boot from or depend on TI QSPI storage without validating recovery options.

How to confirm the fix worked

Confirm whether the system is exposed by checking the running kernel configuration, loaded modules, device tree/platform devices, and driver binding for the TI QSPI SPI controller. Look for CONFIG_SPI_TI_QSPI in the kernel configuration, ti-qspi references in dmesg, and bindings under /sys/bus/platform/drivers/ti-qspi where applicable. Validate remediation by confirming the running kernel package is a vendor-fixed build or by verifying that the driver source contains the corrected error path that clears the DMA channel pointer when buffer allocation fails after DMA setup. After patching, reboot into the fixed kernel and confirm the old vulnerable kernel is not still selected by the bootloader. For high-assurance validation, use a non-production test system with kernel fault injection or allocation-failure testing to exercise the probe failure path and confirm no KASAN, KFENCE, refcount, double-free, DMA engine, or kernel panic reports occur.

Typical attack path

1. Gain local low-privileged execution on a Linux system using the TI QSPI SPI controller driver.
2. Confirm the vulnerable driver is present, built into the kernel, or loaded and bound to compatible hardware.
3. Trigger driver probe, reprobe, unbind, or related device lifecycle paths while creating memory pressure or allocation-failure conditions.
4. Cause DMA setup to partially succeed and the later buffer allocation path to fail, leaving a stale DMA channel pointer.
5. Trigger cleanup, unbind, or subsequent driver operations that pass the freed pointer to the DMA subsystem or release it again.
6. Leverage resulting kernel memory corruption for privilege escalation, or cause a denial-of-service through kernel panic if exploitation is unreliable.

How to detect it

There are no known public exploitation indicators, KEV listing, ransomware association, or named threat-actor activity for this vulnerability. Detection should focus on evidence of attempted local kernel exploitation or instability around the TI QSPI driver. Review kernel logs, persistent journal entries, crash dumps, pstore/ramoops, kdump vmcores, and endpoint telemetry for ti-qspi probe failures, DMA channel cleanup errors, double-free or use-after-free diagnostics, KASAN/KFENCE reports, general protection faults, kernel panics, and unexpected reboots. Pay special attention to events occurring after local user activity, device bind/unbind operations, sysfs driver interactions, module load/unload attempts, or memory-pressure conditions. On hardened or debug kernels, search for stack traces involving the TI QSPI driver, DMA engine channel release paths, driver probe/remove routines, and allocator failure injection. Because exploitation is local, correlate kernel faults with authentication logs, sudo/su usage, new local users, suspicious processes, container workloads, or attempts to access /sys/bus/platform/drivers interfaces.

• ti-qspi
• /sys/bus/platform/drivers/ti-qspi
• CONFIG_SPI_TI_QSPI
• spi-ti-qspi.c
• KASAN: use-after-free
• KFENCE: use-after-free
• BUG: KASAN
• general protection fault
• kernel panic
• dma_release_channel

What your security team should do

• Prioritize patching systems that use TI QSPI hardware, embedded Linux platforms, appliances, lab devices, or multi-user Linux hosts where untrusted local users can execute code.
• Inventory kernels for TI QSPI driver exposure by checking kernel config, loaded modules, platform driver bindings, and vendor hardware bills of material.
• Obtain and deploy vendor-fixed kernel updates; because no exact fixed versions were provided, track the relevant Linux distribution or device vendor advisory rather than relying only on upstream version names.
• Reboot after patching and verify the fixed kernel is the active running kernel, not merely installed on disk.
• If patching is delayed, restrict local shell access, container escape opportunities, device-management privileges, and module-loading capabilities to trusted administrators only.
• Do not attempt to unload or blacklist ti-qspi on production systems until confirming the system does not rely on it for boot flash, storage, firmware, or critical peripherals.
• Enable kernel crash collection and centralized logging for kernel warnings, DMA engine errors, KASAN/KFENCE reports, and unexpected reboots on potentially affected systems.
• Treat any suspicious kernel memory-corruption report involving ti-qspi, DMA cleanup, or driver unbind as a potential exploitation attempt and preserve crash dumps for forensic review.