CVE-2026-31485

What it actually does

CVE-2026-31485 is a Linux kernel use-after-free/null-pointer dereference flaw in the Freescale/NXP LPSPI SPI controller driver, spi-fsl-lpspi. The driver registers the SPI controller using device-managed registration, causing controller unregistration to occur after the driver remove path has already torn down DMA channels. If an SPI transfer is still running while the device is being removed, unbound, or otherwise torn down, the transfer path can reference DMA/controller state that has already been released. At minimum this can crash the kernel; depending on platform configuration and memory reuse behavior, the bug is modeled as potentially allowing local privilege escalation or kernel memory corruption. Exploitation requires local privileges and access to trigger SPI activity, commonly through spidev or another SPI client interface, on systems using this specific LPSPI controller driver.

Why it matters to the business

Affected Linux systems using the Freescale/NXP LPSPI controller may be susceptible to local crashes or compromise when SPI activity overlaps with device or driver teardown. The most likely operational impact is denial of service on embedded, industrial, automotive, IoT, or edge devices where SPI-attached components are critical. Because the CVSS score is high but EPSS is very low, the issue should be prioritized most heavily for systems that expose spidev or allow local users, containers, services, or maintenance workflows to interact with SPI devices. It is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has no public exploit maturity reported, reducing immediate internet-scale urgency.

How an attack unfolds

An attacker first obtains local access to a Linux system that uses the spi-fsl-lpspi driver and has a reachable SPI client interface. The attacker starts one or more SPI transfers, for example through a userspace spidev ioctl path or another local component capable of initiating SPI messages. While a transfer is active, the attacker triggers or races controller teardown, such as by unbinding the platform device, unloading the relevant module where permitted, initiating a hot-remove style path, or otherwise causing the driver remove routine to run. Because the driver tears down DMA channels before the SPI controller is unregistered, an in-flight transfer can continue into fsl_lpspi_dma_transfer or related SPI core paths and dereference freed or null DMA/controller state. A reliable exploit may result in a kernel panic; a more advanced exploit would attempt to shape timing and memory reuse to turn the use-after-free into code execution or privilege escalation in kernel context. Practical exploitation depends strongly on hardware presence, kernel configuration, module permissions, SPI device exposure, and whether unprivileged users can access spidev or trigger device teardown.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, board support package, or long-term kernel branch that includes the spi-fsl-lpspi teardown-order fix. The corrective change replaces devm_spi_register_controller() with explicit spi_register_controller() in fsl_lpspi_probe() and adds spi_unregister_controller() in fsl_lpspi_remove(), ensuring the SPI controller is unregistered before DMA resources are destroyed. No exact fixed package versions were provided, so remediation should be based on vendor advisories or source verification for the specific kernel branch in use. If immediate patching is not possible, reduce exposure by restricting access to /dev/spidev* device nodes, disabling unnecessary spidev userspace interfaces, limiting who can unbind platform devices or unload kernel modules, preventing untrusted local shell/container access on affected devices, and disabling or removing the spi-fsl-lpspi driver only where the hardware function is not required.

How to confirm the fix worked

Confirm whether the system is exposed by checking whether the kernel includes and loads the spi-fsl-lpspi driver and whether the hardware uses an affected Freescale/NXP LPSPI controller. Validate remediation by verifying the installed kernel source or vendor patch contains explicit spi_register_controller() and spi_unregister_controller() usage in the spi-fsl-lpspi driver rather than relying on devm_spi_register_controller() for controller registration. Operationally, confirm that the updated kernel boots, the SPI devices still function, and repeated SPI transfers during controlled driver unbind/rebind or shutdown testing no longer produce kernel warnings, null-pointer dereferences, DMA RX I/O errors, or panics. For package-based systems, verify the running kernel version matches the vendor-advised fixed build, not merely that an updated package is installed but not yet booted.

Typical attack path

1. Identify a Linux system using the Freescale/NXP LPSPI controller driver, typically visible as spi_fsl_lpspi or a platform device such as fsl_lpspi.
2. Gain local access with enough privileges to interact with an SPI device or spidev node.
3. Initiate repeated or long-running SPI transfers to keep the LPSPI DMA transfer path active.
4. Trigger device or driver teardown, such as unbinding the SPI controller, unloading a module, or causing a remove path while transfers are active.
5. Race the teardown so DMA resources are released before the SPI controller is fully unregistered.
6. Cause a kernel null-pointer dereference, use-after-free, system crash, or potentially kernel memory corruption.
7. If pursuing privilege escalation, attempt to control memory reuse and execution flow after the freed state is referenced.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, persistent journal entries, serial console captures, crash dumps, and appliance watchdog/reset logs. Key sources include dmesg output, systemd-journald kernel facility logs, /var/log/kern.log, /var/log/messages, pstore/ramoops records, kdump vmcores, audit logs for module loading or sysfs driver unbind operations, and file-access telemetry for spidev device nodes. Suspicious patterns include LPSPI DMA RX I/O errors immediately followed by a kernel NULL pointer dereference, stack traces containing fsl_lpspi_dma_transfer, fsl_lpspi_transfer_one, spi_transfer_one_message, spidev_message, or spidev_ioctl, and administrative actions such as writing to /sys/bus/platform/drivers/*/unbind while SPI transfers are active. Because this is a local kernel race condition, network IOCs are not expected. Focus detection on local process activity accessing /dev/spidev*, kernel oops/panic artifacts, unusual driver unbind/rebind operations, module unload attempts involving spi_fsl_lpspi, and repeated device resets or watchdog reboots on platforms using this controller.

• fsl_lpspi 42550000.spi: I/O Error in DMA RX
• I/O Error in DMA RX
• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
• fsl_lpspi_dma_transfer
• fsl_lpspi_transfer_one
• spi_transfer_one_message
• __spi_pump_transfer_message
• __spi_sync
• spi_sync
• spidev_message
• spidev_ioctl
• spi_fsl_lpspi
• spidev
• /dev/spidev
• /dev/spidev*
• /sys/bus/platform/drivers/fsl_lpspi/unbind
• /sys/bus/platform/drivers/spi-fsl-lpspi/unbind
• /sys/bus/platform/drivers/fsl_lpspi/bind
• /sys/bus/platform/drivers/spi-fsl-lpspi/bind
• modprobe -r spi_fsl_lpspi
• rmmod spi_fsl_lpspi
• kernel NULL pointer dereference
• Call trace:
• Oops:
• Kernel panic

What your security team should do

• Prioritize patching embedded, edge, industrial, and appliance systems that use Freescale/NXP LPSPI hardware and expose spidev or local maintenance shells.
• Inventory Linux kernels and board support packages for use of the spi-fsl-lpspi driver, including vendor-custom kernels that may not track mainline fixes quickly.
• Restrict permissions on /dev/spidev* and remove unnecessary users from groups that can access SPI character devices.
• Restrict module loading/unloading and sysfs driver unbind operations to trusted administrators only.
• Review container and service configurations to ensure untrusted workloads cannot access host SPI devices or privileged sysfs device-management paths.
• Monitor kernel logs for LPSPI DMA errors, null-pointer dereferences, and stack traces involving spi_fsl_lpspi, spidev_ioctl, or fsl_lpspi_dma_transfer.
• After patching, reboot into the fixed kernel and confirm the running kernel, not just the installed package, contains the fix.
• Treat unexplained crashes on affected platforms during SPI operations or driver teardown as potentially security-relevant until logs are reviewed.