CVE-2026-45996

What it actually does

This vulnerability is a use-after-free in the Linux kernel i.MX SPI controller driver during device or driver unbind. When the SPI controller is deregistered, the SPI subsystem may free controller-associated driver data before the driver has finished using it. A local attacker with sufficient privileges to trigger driver unbind or related device-management paths could potentially cause kernel memory corruption. Depending on kernel configuration, hardware exposure, and exploit reliability, this can lead to local privilege escalation, kernel crash, or compromise of kernel memory confidentiality and integrity.

Why it matters to the business

Affected Linux systems using the i.MX SPI driver may be exposed to local privilege escalation or denial-of-service risk. The most likely operational impact is a system crash or instability on embedded, appliance, industrial, or ARM-based platforms that rely on i.MX SPI hardware. Because exploitation requires local access and the issue is not currently listed in CISA KEV, has no known mature public exploit, and has a very low EPSS score, broad internet-scale exploitation is unlikely; however, organizations operating multi-user Linux systems or products that expose local shell, container escape paths, or device-management interfaces should still prioritize patching during normal kernel maintenance cycles.

How an attack unfolds

An attacker first obtains local code execution or an account on a vulnerable Linux system where the i.MX SPI controller driver is present and reachable. The attacker then attempts to trigger the vulnerable unbind or deregistration path, such as through sysfs driver unbind mechanisms or other device-removal workflows available to the attacker’s privilege level. During controller deregistration, the SPI subsystem can free driver data that the driver later continues to access. By carefully shaping timing and heap state, an attacker may attempt to turn the resulting use-after-free into controlled kernel memory corruption. Successful exploitation could allow kernel privilege escalation or arbitrary kernel memory access; unsuccessful attempts may simply crash the system or produce kernel warnings, oopses, or panics. No known exploitation campaigns or ransomware use are currently reported for this vulnerability.

How to fix it

Update affected Linux kernels to a vendor-supported build that includes the upstream fix for the i.MX SPI driver use-after-free on unbind. Because no exact fixed package versions were provided, use the latest stable kernel or distribution security kernel available for the affected product line and confirm that the patch referencing `spi: imx: fix use-after-free on unbind` is included. Reboot systems after kernel updates so the fixed kernel is active. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting administrative access to sysfs device unbind paths, disabling or blacklisting the i.MX SPI driver if it is not required, and applying least-privilege controls to services or containers that could reach device-management interfaces. For embedded or appliance environments, obtain patched firmware or BSP updates from the device or silicon vendor.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot. Validate vendor advisories, changelogs, or kernel source package history for inclusion of the i.MX SPI fix. On source-based or custom kernels, verify the driver now takes an additional reference before deregistering the SPI controller so driver data is not freed before cleanup completes. Check whether the affected driver is present or loaded using kernel module and device inventory tools. If mitigation was applied instead of patching, confirm the i.MX SPI driver is disabled or unavailable and that unprivileged users cannot write to relevant sysfs driver unbind paths. Functional testing should include SPI device attach/detach, driver unbind/rebind, suspend/resume, and boot-time hardware initialization to ensure the patched driver remains stable.

Typical attack path

1. Gain local access to a vulnerable Linux system, such as through a shell, compromised service account, malicious package, or other foothold.
2. Confirm the system uses an affected kernel build and has the i.MX SPI controller driver loaded or available.
3. Trigger SPI controller removal, driver unbind, or a related deregistration path that reaches the vulnerable cleanup logic.
4. Attempt to manipulate kernel heap state around the freed SPI controller driver data.
5. Abuse the use-after-free condition to cause kernel memory corruption, escalate privileges, or crash the host.
6. Use elevated privileges to persist, access protected data, disable security controls, or move laterally if the system is part of a larger fleet.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs and crash telemetry rather than relying on network indicators, because exploitation is local and device-driver specific. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump repositories, pstore/ramoops logs on embedded systems, audit logs for sysfs writes, and EDR telemetry for local commands interacting with driver bind/unbind paths. Look for kernel oopses, panics, KASAN or slab use-after-free reports, NULL or invalid pointer dereferences, warnings involving `spi_imx`, `spi-imx`, SPI controller deregistration, or driver unbind activity. Also review auditd or shell history for suspicious writes to `/sys/bus/platform/drivers/*/unbind`, repeated driver unbind/rebind attempts, or unexpected manipulation of SPI platform devices. Absence of logs does not prove absence of exploitation, especially on embedded systems without persistent kernel logging, but repeated crashes or memory-safety reports around SPI unbind paths should be treated as suspicious.

• spi_imx
• spi-imx
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• Unable to handle kernel paging request
• general protection fault
• slab-use-after-free
• /sys/bus/platform/drivers/spi_imx/unbind
• /sys/bus/platform/drivers/spi-imx/unbind
• /sys/bus/platform/drivers/*/unbind
• echo * > /sys/bus/platform/drivers/*/unbind
• driver unbind
• spi_controller_unregister
• spi_unregister_controller

What your security team should do

• Prioritize inventory of Linux systems, embedded devices, appliances, and ARM/i.MX-based platforms that include or load the i.MX SPI driver.
• Patch affected systems with vendor-supported kernels containing the upstream fix, then reboot to activate the corrected kernel.
• For systems that cannot be patched quickly, restrict local access and administrative device-management capabilities, especially access to sysfs driver bind and unbind controls.
• Review kernel crash, oops, and panic telemetry for SPI, imx, use-after-free, slab, KASAN, or controller deregistration messages that may indicate attempted triggering or instability.
• Coordinate with embedded device, firmware, and BSP vendors to obtain fixed builds where kernel updates are bundled into product firmware.
• Treat exploitation as lower urgency than remotely exploitable KEV vulnerabilities because current EPSS is very low, there is no known mature exploit, and exploitation requires local access; nevertheless, include it in routine kernel security patch cycles.