CVE-2026-46200

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel MPC52xx SPI controller driver. During driver unbind, the driver could disable and release underlying resources such as interrupts and GPIOs before deregistering the SPI controller. That incorrect teardown order can leave kernel SPI infrastructure referencing resources that have already been released, potentially causing a kernel crash, hang, or other availability failure when the controller is accessed during or after unbind. Exploitation requires local access with sufficient privileges to trigger driver unbinding, module removal, or equivalent device-management operations on affected systems using the MPC52xx SPI controller driver.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing service interruption, device downtime, or loss of availability for embedded, industrial, appliance, or other PowerPC/MPC52xx-based deployments that rely on this kernel driver. The current exploitation likelihood appears low: EPSS is 0.00127, it is not listed in CISA KEV, and no public exploit maturity is reported. However, because the impact is availability loss at the kernel level, affected operational systems should still be patched during normal maintenance windows, with higher priority for systems where local users, containers, or automation can perform device or module management operations.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with privileges sufficient to interact with kernel driver lifecycle controls, such as unbinding the MPC52xx SPI platform driver or unloading a related module. The attacker then triggers driver unbind or teardown while the SPI controller is still registered with the kernel SPI subsystem. Because the vulnerable driver releases interrupts, GPIOs, or other resources before deregistering the controller, subsequent kernel activity may reference freed or disabled resources. This can result in a kernel oops, panic, system hang, or loss of SPI-related functionality, producing a denial of service. There is no indication from the provided data that this flaw enables remote code execution, privilege escalation, data theft, or ransomware use.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the MPC52xx SPI controller deregistration order. The corrected behavior deregisters the SPI controller before disabling and releasing interrupts, GPIOs, and other underlying resources during driver unbind. No exact fixed package versions were provided, so obtain patched kernels from the relevant Linux distribution, vendor BSP, embedded platform vendor, or long-term-support kernel branch. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting sudo/root permissions for driver lifecycle operations, preventing untrusted users from writing to sysfs driver bind/unbind interfaces, disabling unnecessary module unload operations, and avoiding manual unbind/rebind of the MPC52xx SPI driver on production systems. If the affected hardware or driver is not in use, consider disabling the driver in the kernel configuration or preventing it from loading.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the MPC52xx SPI driver and whether the platform uses MPC52xx SPI hardware. Validate remediation by confirming the installed kernel package or source tree contains the patch that deregisters the SPI controller before releasing IRQ/GPIO resources in the MPC52xx SPI driver. Reboot into the patched kernel if required by the distribution or vendor. On non-production test systems, controlled driver unbind/rebind testing can be used to confirm the system no longer crashes or logs kernel oops messages during teardown. Review kernel logs after validation for absence of crashes, warnings, or stack traces involving the MPC52xx SPI driver, SPI controller deregistration, IRQ teardown, or GPIO release paths.

Typical attack path

1. Gain local access to an affected Linux system running the vulnerable kernel driver.
2. Obtain or use privileges that allow driver unbind, module unload, or low-level device-management operations.
3. Identify the MPC52xx SPI controller driver or associated platform device.
4. Trigger driver unbind, module removal, or repeated teardown/rebind activity.
5. Cause the driver to release interrupts/GPIOs before the SPI controller is fully deregistered.
6. Provoke or wait for SPI subsystem activity that references released resources.
7. Result in kernel instability, oops, panic, hang, or loss of availability.

How to detect it

Look for evidence of local driver lifecycle manipulation followed by kernel instability. Useful sources include kernel logs, system journal, audit logs, sudo logs, shell history where available, endpoint telemetry, and change-management records for module or driver operations. In kernel logs, search for oops, panic, warning, IRQ, GPIO, SPI, or MPC52xx-related messages around the time of service interruption. In audit logs, look for writes to sysfs driver unbind files, executions of rmmod, modprobe, driverctl, or scripts that manage platform devices. Because this is a local denial-of-service issue, exploitation evidence may be limited to a crash, reboot, watchdog reset, or kernel stack trace rather than a persistent malware artifact. Correlate any kernel crash with preceding privileged commands or sysfs writes involving the MPC52xx SPI driver. There are no known threat actors, KEV listing, ransomware campaigns, or public exploit artifacts associated with the provided data.

• /sys/bus/platform/drivers/mpc52xx-spi/unbind
• /sys/bus/platform/drivers/mpc52xx-psc-spi/unbind
• drivers/spi/spi-mpc52xx.c
• mpc52xx-spi
• mpc52xx-psc-spi
• spi-mpc52xx
• rmmod spi_mpc52xx
• modprobe -r spi_mpc52xx
• driverctl unset-override
• driverctl unbind
• echo * > /sys/bus/platform/drivers/*/unbind
• Kernel panic
• Oops:
• BUG: unable to handle kernel
• Unable to handle kernel NULL pointer dereference
• WARNING: CPU:
• spi_unregister_controller
• spi_controller_unregister
• free_irq
• gpiod_put

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and vendor BSPs that use MPC52xx/PowerPC hardware or include the MPC52xx SPI controller driver.
• Prioritize patching affected systems where local users, maintenance accounts, containers, scripts, or device-management services can trigger driver unbind or module unload operations.
• Request fixed kernel versions or BSP updates from the Linux distribution, hardware vendor, or appliance vendor if package-level fixed versions are not published.
• Restrict write access to sysfs driver bind/unbind paths and limit sudo/root permissions for modprobe, rmmod, driverctl, and equivalent device-management tooling.
• Monitor for suspicious driver unbind/rebind activity and kernel oops or panic events involving SPI or MPC52xx driver code.
• For critical operational systems, schedule kernel updates through normal change-control windows and ensure rollback or console access is available in case of kernel upgrade issues.
• If the affected SPI controller is not required, disable or blacklist the driver where operationally safe.