CVE-2026-31485: Linux Kernel SPI Driver UAF Vulnerability

CVE-2026-31485 Overview

CVE-2026-31485 is a Use After Free (UAF) vulnerability in the Linux kernel's SPI (Serial Peripheral Interface) subsystem, specifically affecting the spi-fsl-lpspi driver. The vulnerability stems from a teardown order issue where the SPI controller unregistration is delayed until after the fsl_lpspi_remove() function returns, while DMA channels are synchronously torn down within the remove function.

This race condition creates a window where a running SPI transfer can attempt to access freed DMA resources, resulting in a NULL pointer dereference and potential system crash or exploitation.

Critical Impact

Local attackers with access to SPI devices can trigger a kernel NULL pointer dereference, causing system instability or denial of service. The UAF condition may potentially be exploited for privilege escalation.

Affected Products

• Linux Kernel with spi-fsl-lpspi driver enabled
• NXP/Freescale platforms using LPSPI controllers
• Embedded systems utilizing SPI communication via the affected driver

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-31485 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31485

Vulnerability Analysis

The vulnerability exists in the spi-fsl-lpspi driver's device teardown sequence. The driver uses devm_spi_register_controller() to register the SPI controller, which ties the unregistration to the device's managed resource lifecycle. This means the SPI controller remains registered and potentially active even after fsl_lpspi_remove() begins execution.

Within fsl_lpspi_remove(), the DMA channels are synchronously released. However, if an SPI transfer is in progress at this point, the transfer continues to execute on the still-registered controller while attempting to access DMA resources that have already been freed. This results in the observed NULL pointer dereference in fsl_lpspi_dma_transfer().

The kernel crash trace clearly shows the execution path from userspace (spidev_ioctl) through the SPI subsystem (spi_sync, spi_transfer_one_message) to the affected driver function, indicating the vulnerability can be triggered through normal SPI device access.

Root Cause

The root cause is improper resource lifecycle management in the driver. By using devm_spi_register_controller(), the driver delegates controller unregistration to the devm (device-managed) framework, which occurs after all explicit cleanup in the remove function completes.

This creates an ordering problem where:

1. fsl_lpspi_remove() is called during device removal
2. DMA channels are freed within this function
3. The function returns, but the SPI controller is still registered
4. Only after the function returns does devm unregister the controller
5. Any SPI transfers initiated between steps 2 and 4 will access freed DMA resources

Attack Vector

The vulnerability can be exploited locally by a user with access to an SPI device (typically /dev/spidevX.Y). The attack requires triggering an SPI transfer during the brief window when the device is being removed but the controller is still active.

An attacker could initiate an SPI transfer via the spidev interface and then trigger device removal (e.g., through unbinding the driver or hot-unplugging hardware if supported). The timing window, while narrow, can potentially be widened through various techniques common in race condition exploitation.

The crash manifests as a kernel NULL pointer dereference at address 0x0000000000000000, as shown in the kernel trace where fsl_lpspi_dma_transfer+0x260/0x340 attempts to access the freed DMA descriptor.

Detection Methods for CVE-2026-31485

Indicators of Compromise

• Kernel oops or panic messages referencing fsl_lpspi_dma_transfer or spi_fsl_lpspi module
• System logs showing "I/O Error in DMA RX" from fsl_lpspi driver
• Unexpected NULL pointer dereference crashes on systems using NXP/Freescale LPSPI hardware
• Repeated system instability during SPI device removal or driver unloading

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for stack traces involving spi_fsl_lpspi module
• Implement kernel crash dump analysis to identify UAF patterns in the SPI subsystem
• Use kernel debugging tools like KASAN (Kernel Address Sanitizer) to detect use-after-free conditions
• Deploy runtime integrity monitoring to detect anomalous kernel memory access patterns

Monitoring Recommendations

• Enable kernel crash reporting mechanisms (kdump, crash) for post-incident analysis
• Configure alerting on kernel oops events, particularly those involving SPI-related symbols
• Implement system stability monitoring on embedded devices using the affected LPSPI driver
• Review audit logs for suspicious device removal or driver unbinding operations

How to Mitigate CVE-2026-31485

Immediate Actions Required

• Apply the kernel patch that switches from devm_spi_register_controller() to spi_register_controller()
• Update to a patched kernel version containing the fix
• Restrict access to SPI devices (/dev/spidev*) to trusted users and applications
• Avoid hot-removing or unbinding the spi-fsl-lpspi driver while SPI transfers may be in progress

Patch Information

The fix involves changing the SPI controller registration to use explicit lifecycle management rather than devm. The patch modifies fsl_lpspi_probe() to call spi_register_controller() instead of devm_spi_register_controller(), and adds a corresponding spi_unregister_controller() call at the beginning of fsl_lpspi_remove().

This ensures the SPI controller is unregistered and all pending transfers are completed or cancelled before any DMA resources are freed.

Multiple patch commits are available for different kernel branches:

• Kernel Git Commit 15650dfbaeeb
• Kernel Git Commit adb25339b661
• Kernel Git Commit b341c1176f2e
• Kernel Git Commit ca4483f36ac1

Workarounds

• Restrict access to SPI device nodes using filesystem permissions (e.g., chmod 600 /dev/spidev*)
• Disable automatic driver binding/unbinding if not required for the use case
• Implement application-level locking to prevent SPI transfers during device removal
• Consider using a statically compiled kernel module that cannot be unloaded at runtime

# Configuration example
# Restrict SPI device access to root only
chmod 600 /dev/spidev*
chown root:root /dev/spidev*

# Prevent automatic driver unbinding
echo 1 > /sys/bus/spi/drivers_autoprobe

# Alternative: blacklist driver unloading at runtime
echo "install spi_fsl_lpspi /bin/true" >> /etc/modprobe.d/spi-protect.conf