CVE-2024-26866

What it actually does

Use-after-free in fsl_lpspi_probe() caused by mixing manual spi_alloc_host/spi_controller_put with devm_spi_register_controller, resulting in spi_unregister_controller being invoked after explicit free and potential NULL pointer dereference during device removal.

Why it matters to the business

Kernel crashes or instability on systems using the affected LPSPI controller can interrupt hardware-dependent workloads, reduce availability of embedded or industrial Linux devices, and increase operational overhead for patching fleets of affected kernels.

How an attack unfolds

An attacker with the ability to trigger driver probe (via module load, device insertion, or error injection during initialization) forces an error path after devm registration; the subsequent manual put combined with devm cleanup then dereferences freed memory, manifesting as a kernel panic.

How to fix it

Update the Linux kernel to the commit da83ed350e4604b976e94239b08d8e2e7eaee7ea or later stable releases that contain the corrected probe error handling; rebuild and deploy the updated kernel image on all affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit da83ed350e4604b976e94239b08d8e2e7eaee7ea, review dmesg for absence of the described call trace during LPSPI probe failures, and verify spi controller registration succeeds without subsequent use-after-free panics under error conditions.

Typical attack path

1. Identify or create conditions that cause fsl_lpspi_probe to fail after devm_spi_register_controller succeeds
2. Trigger the probe error path leading to explicit spi_controller_put
3. Allow devm release machinery to invoke spi_unregister_controller on already-freed memory
4. Observe resulting kernel NULL pointer dereference and system instability

How to detect it

Search kernel logs and crash dumps for the call trace containing spi_unregister_controller, devm_spi_unregister, and kernfs_find_ns during device probe; correlate with LPSPI controller initialization failures on systems that have not yet applied the fix.

What your security team should do

• Prioritize kernel updates on all systems exposing the LPSPI driver within the next maintenance window
• Monitor kernel logs for spi_unregister_controller and kernfs NULL dereference patterns until patched
• Test the updated kernel in a staging environment that exercises probe error paths before broad rollout