CVE-2026-64303

What it actually does

This is a Linux kernel memory-safety flaw in the Freescale/NXP LPSPI SPI controller driver. If TX DMA descriptor preparation fails after the RX DMA channel has already been submitted, the driver terminates only the TX channel and returns an error while the SPI core unmaps the DMA buffers. The still-running RX DMA engine can then continue writing into unmapped, freed, or reused memory, creating a use-after-free/memory-corruption condition in kernel context. Successful exploitation could potentially cause kernel crashes, data corruption, information disclosure, or kernel-mode code execution depending on platform behavior, memory layout, and the attacker’s ability to trigger the vulnerable SPI DMA error path.

Why it matters to the business

Systems using affected Linux kernels on hardware with the fsl-lpspi driver may be vulnerable to severe kernel-level compromise or instability. Operational consequences can include device crashes, corrupted data, denial of service, or full system takeover if an attacker can reliably control the vulnerable SPI transfer path. Although the CVSS rating is critical, current public exploitation maturity is listed as none, EPSS is low, the issue is not in CISA KEV, and there is no known ransomware association; however, kernel memory-corruption bugs should still be prioritized on exposed embedded, industrial, edge, automotive, appliance, or IoT systems where SPI devices are accessible to untrusted code or peripherals.

How an attack unfolds

An attacker first needs a way to cause SPI transfers through an affected fsl-lpspi controller, such as local access to a userspace SPI interface, compromise of software that talks to SPI devices, or control of an attached peripheral or workload capable of influencing transfer behavior. The attacker then repeatedly initiates or induces SPI DMA transfers while attempting to trigger failure in dmaengine_prep_slave_sg() for the TX channel after the RX channel has already been issued. In the vulnerable error path, the driver returns failure without terminating the RX DMA channel. The SPI core proceeds to unmap DMA buffers, but RX DMA may continue writing into memory that is no longer valid for that transfer. At minimum this can crash the kernel or corrupt data; with reliable heap shaping and platform-specific knowledge, the stale DMA writes may be used to corrupt kernel memory and potentially escalate privileges or execute code in kernel context.

How to fix it

Apply a Linux kernel update that includes the fsl-lpspi fix which terminates the RX DMA channel when TX DMA preparation fails. If a vendor kernel update is not yet available, backport the upstream patch described as terminating the RX channel on the TX prepare failure path in the fsl-lpspi SPI driver. For systems that cannot be immediately patched, reduce exposure by disabling unused SPI interfaces, removing or blacklisting the fsl-lpspi driver where feasible, disabling userspace SPI device nodes such as /dev/spidev* for untrusted users, restricting services that proxy SPI access, and disabling SPI DMA or the affected controller in board configuration/device tree if supported. Treat compensating controls as temporary because the vulnerable behavior occurs in kernel context.

How to confirm the fix worked

Confirm that the running kernel or vendor kernel package contains the fix for the fsl-lpspi RX termination error path. Validate by reviewing vendor advisories, kernel changelogs, or the source for drivers/spi/spi-fsl-lpspi.c to ensure the RX DMA channel is terminated before returning when TX dmaengine_prep_slave_sg() fails. On deployed systems, verify the active kernel version after reboot, confirm whether fsl-lpspi is loaded or built in, and inventory exposed SPI device nodes. Where safe in a test environment, exercise SPI DMA error paths and confirm no KASAN, DMA API, slab corruption, or kernel oops messages appear.

Typical attack path

1. Identify a Linux system running an affected kernel on hardware using the Freescale/NXP LPSPI driver.
2. Gain a path to trigger SPI transfers, such as access to /dev/spidev*, a vulnerable application using SPI, or control over an SPI-connected component.
3. Initiate SPI DMA transactions where the RX channel is submitted before TX descriptor preparation completes.
4. Force or race a TX dmaengine_prep_slave_sg() failure after RX DMA has already been issued.
5. Allow the SPI core to unmap DMA buffers while RX DMA continues writing to those buffers.
6. Use the resulting kernel memory corruption to cause denial of service, corrupt sensitive kernel data, disclose information, or attempt privilege escalation.

How to detect it

There are no known public exploit indicators or KEV-listed exploitation for this vulnerability at this time. Detection should focus on evidence of attempted triggering or consequences of kernel memory corruption on systems using the fsl-lpspi driver. Review kernel logs, persistent journal logs, crash dumps, pstore/ramoops records, and monitoring telemetry for SPI/DMA errors followed by use-after-free, slab corruption, page faults, kernel oops, panics, or unexpected reboots. On kernels built with KASAN, KFENCE, UBSAN, or DMA API debugging, look for reports involving fsl-lpspi, spi-fsl-lpspi.c, DMA unmapping, dmaengine callbacks, or writes after free. Correlate suspicious events with access to userspace SPI device nodes, application logs from services that communicate with SPI peripherals, recent firmware/peripheral changes, or repeated SPI transaction failures. Because exploitation may manifest only as generic kernel instability, absence of logs does not prove absence of exploitation, especially on devices without persistent kernel logging.

• fsl-lpspi
• spi-fsl-lpspi.c
• dmaengine_prep_slave_sg
• KASAN: use-after-free
• BUG: unable to handle kernel paging request
• slab-out-of-bounds
• kernel BUG at drivers/spi
• DMA-API: device driver maps memory from stack
• DMA-API: device driver tries to free DMA memory it has not allocated
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• /dev/spidev

What your security team should do

• Prioritize patching embedded, edge, appliance, OT, and IoT systems that use Freescale/NXP LPSPI hardware or expose SPI access to applications or users.
• Inventory Linux kernels and hardware platforms for use of the fsl-lpspi driver, including vendor-maintained downstream kernels.
• Restrict access to /dev/spidev* and any application interfaces that allow untrusted users to initiate SPI transfers.
• Monitor kernel logs for DMA, SPI, KASAN, slab corruption, and unexplained crash indicators on systems with fsl-lpspi enabled.
• If patching is delayed, disable unused SPI controllers or SPI DMA functionality where operationally feasible.
• Track vendor kernel advisories because fixed package versions were not provided in the input and may vary by distribution, BSP, or appliance firmware.
• Do not rely on the low EPSS score alone; kernel memory corruption on specialized hardware can have high impact even when broad internet exploitation is unlikely.