CVE-2026-46219

What it actually does

This is a Linux kernel use-after-free condition in the MPC52xx SPI controller driver. The driver’s interrupt handler can schedule deferred state-machine work, and during device unbind/removal that work may remain queued after resources have been freed. If the queued work runs after teardown, the kernel may dereference freed memory. A local attacker with sufficient privileges to trigger device unbind or influence driver lifecycle could potentially cause kernel memory corruption, leading to a crash or possible local privilege escalation depending on kernel configuration, memory layout, and exploit reliability.

Why it matters to the business

Affected systems can suffer local denial of service through kernel crashes, and in the worst case an attacker with local access may gain elevated privileges on vulnerable Linux hosts. The impact is most relevant to embedded, industrial, or specialized PowerPC/MPC52xx-based systems using the affected SPI driver. EPSS is currently very low, it is not listed in CISA KEV, and there is no reported public exploit maturity, so broad internet-scale exploitation is unlikely; however, kernel privilege-escalation bugs remain important where untrusted local users, containers, appliances, or physical/service access are in scope.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system where the MPC52xx SPI driver is present and active. The attacker then attempts to trigger driver unbind/removal while SPI interrupt-driven state-machine work is pending. Because the vulnerable driver can free teardown-related state before all scheduled work has been cancelled, the deferred work may later execute against freed memory. A basic attack may simply crash the kernel, producing a denial of service. A more advanced exploit would attempt to shape freed kernel memory and reclaim it with attacker-controlled data so that the stale work item dereference corrupts kernel state in a useful way, potentially enabling privilege escalation. There are no known named threat actors or ransomware campaigns associated with this issue based on the supplied data.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the MPC52xx SPI driver use-after-free on unbind. The fix ensures deferred state-machine work is cancelled after interrupts are disabled during teardown, preventing the queued work from accessing freed state. Because exact fixed package versions were not provided, use the relevant distribution/vendor advisory for the precise patched kernel version. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the mpc52xx SPI driver if it is not required, restricting access to device-driver unbind interfaces, limiting local shell access, disabling unnecessary module loading/unloading paths, and applying standard kernel hardening such as lockdown mode, module-signing enforcement, SELinux/AppArmor confinement, and least-privilege controls.

How to confirm the fix worked

Confirm the running kernel contains the upstream or vendor backport that cancels the MPC52xx SPI state-machine work after interrupts are disabled during unbind. Validate through the OS vendor package changelog, kernel source package, or advisory notes referencing the mpc52xx SPI unbind use-after-free fix. On systems where source verification is possible, inspect the affected driver implementation for teardown logic that disables interrupts before cancelling pending work. Confirm whether the affected driver is present or loaded using kernel module inventory, device-tree/platform-driver enumeration, and boot logs. If feasible in a controlled test environment, exercise driver unbind/removal with kernel sanitizers or debug kernels enabled and verify that no KASAN use-after-free, workqueue, or kernel oops messages are produced.

Typical attack path

1. Obtain local access to a Linux system running the affected MPC52xx SPI driver.
2. Confirm the vulnerable driver/device is present and that device unbind or driver teardown can be triggered.
3. Create timing conditions where SPI interrupt handling schedules deferred state-machine work.
4. Trigger device unbind/removal before the scheduled work has been safely cancelled.
5. Cause the queued work to execute after driver resources have been freed.
6. Leverage the resulting use-after-free for a kernel crash or attempt controlled memory corruption for privilege escalation.

How to detect it

Look for evidence of kernel memory-safety faults, crashes, or suspicious driver lifecycle activity involving the MPC52xx SPI driver. Relevant sources include kernel ring buffer output, persistent system journals, serial console logs, crash dumps, kdump/vmcore artifacts, audit logs for writes to sysfs driver unbind files, and endpoint telemetry showing module unload or driver unbind operations. Search for KASAN use-after-free reports, kernel oops or panic messages, workqueue faults, and stack traces referencing the MPC52xx SPI driver or SPI state-machine work. Because no public exploit or threat actor activity is reported, detection should focus on anomalous local attempts to unbind platform devices, repeated kernel crashes shortly after SPI activity, and crash traces where deferred work executes after driver teardown.

• BUG: KASAN: use-after-free
• use-after-free
• kernel BUG
• Oops:
• Kernel panic
• Unable to handle kernel paging request
• workqueue
• mpc52xx
• mpc52xx_spi
• mpc52xx-spi
• spi: mpc52xx
• /sys/bus/platform/drivers/mpc52xx-spi/unbind
• /sys/bus/platform/drivers/mpc52xx_spi/unbind
• unbind

What your security team should do

• Prioritize patching Linux systems that use MPC52xx/PowerPC embedded platforms or have the mpc52xx SPI driver enabled.
• Use vendor kernel advisories to identify the exact patched kernel package for each supported distribution or appliance image.
• Inventory systems for the presence of the mpc52xx SPI driver and associated platform devices; treat systems without this driver or hardware as lower priority.
• Restrict local administrative actions that can unbind devices, unload drivers, or manipulate kernel modules.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or workqueue errors involving the mpc52xx SPI driver.
• If patching is delayed and the SPI controller is not operationally required, disable or blacklist the affected driver.
• For embedded or appliance fleets, incorporate the patched kernel into firmware build pipelines and regression-test SPI-dependent functionality before deployment.