CVE-2024-26866 - Critical Use-After-Free Bug in Linux Kernel’s LPSPI Driver – Explained (with Exploit Details)
On February 26, 2024, a significant vulnerability was identified in the Linux kernel’s spi-lpspi driver, tagged as CVE-2024-26866. This bug could lead to a use-after-free memory error during the device probing process, potentially causing kernel panics or offering a foothold for privilege escalation. In this post, we break down what happened, what the code looked like, how it was fixed, and what this means for Linux users and developers. This is an exclusive, plain-English rundown with concrete exploit details and useful references.
What is CVE-2024-26866?
CVE-2024-26866 affects the NXP/Freescale SPI driver in the Linux kernel, specifically the fsl_lpspi (“Low Power Serial Peripheral Interface”) hardware interface. The vulnerability is a use-after-free error in the driver’s probe() function.
When a device is initialized, the kernel’s *probe* routine is called to set things up. The problem here is how resources get allocated, registered, and freed *on error paths*. A mismatch between manual memory management and “devm” (device-managed) cleanup helpers could leave a chunk of memory being freed twice, or being used after it has already been freed — which is a recipe for disaster in kernel space.
Original Problematic Code (before patch)
static int fsl_lpspi_probe(struct platform_device *pdev) {
/* ... */
struct spi_controller *ctlr;
/* Manual allocation */
ctlr = spi_alloc_host(dev, sizeof(...));
/* ... */
/* Registers using device-managed helper */
ret = devm_spi_register_controller(&pdev->dev, ctlr);
if (ret) {
/* On error, manual cleanup */
spi_controller_put(ctlr); // <-- Freed here
return ret;
}
/* ... */
}
On error after devm_spi_register_controller, it’s manually freed with spi_controller_put().
- But: devm_spi_register_controller() takes ownership and expects to free it automatically on device removal or other error paths.
- So, if something goes wrong, there’s a chance spi_controller_put() is called too early, but the kernel’s "devm" mechanism will still try to use or free it later.
This causes a classic use-after-free: an object is freed and then used later = crash, or possibly even arbitrary code execution if cleverly exploited.
Triggering the Bug: Exploit Path
In the wild, a malicious or buggy device tree entry, or a user racing hotplug/unplug events, could force the error path by making devm_spi_register_controller() fail. This sets up the scenario:
The “devm” cleanup *also* tries to free (or use) the same struct during resource unwinding.
This results in a NULL pointer dereference, use-after-free, or even memory corruption, depending on circumstances.
Sample crash trace from affected kernels
Unable to handle kernel NULL pointer dereference at virtual address 000000000000007
Call trace:
kernfs_find_ns
kernfs_find_and_get_ns
sysfs_remove_group
sysfs_remove_groups
device_remove_attrs
device_del
spi_unregister_controller
devm_spi_unregister
release_nodes
devres_release_all
really_probe
driver_probe_device
...
How Was CVE-2024-26866 Fixed?
The patch fixes the allocation and cleanup pattern so that everything is handled with device-managed helpers ("devm") from start to finish, or falls back to strict manual allocation/freeing — but never mixes both.
Patched/Fixed Code
static int fsl_lpspi_probe(struct platform_device *pdev) {
/* ... */
struct spi_controller *ctlr;
/* Use proper devm allocation */
ctlr = devm_spi_alloc_host(&pdev->dev, sizeof(...));
/* ... */
/* Now resource management is consistent */
ret = devm_spi_register_controller(&pdev->dev, ctlr);
if (ret)
return ret; // No manual spi_controller_put() needed
/* ... */
}
Key point:
Can This Be Exploited in Practice?
If you can trick the kernel into hitting the error path in fsl_lpspi_probe() (say, with carefully crafted hardware, device tree entries, or racing hotplug events), you could trigger an accidental double-free or use-after-free.
System crash (DoS — Denial of Service)
- Escalation to arbitrary read/write (unlikely, but theoretically possible with heap spraying and advanced techniques)
Local privilege escalation in rare cases
No wormable or remote vector is known to exist. This bug is mainly of interest to those in embedded Linux fields, researchers, and kernel security teams.
## How Do I Fix/Protect Against This Bug?
- Upgrade your kernel to a version with the patch applied. Mainline kernels after Feb 26, 2024, are safe.
- If you maintain an out-of-tree kernel or vendor tree, apply this patch manually.
Patch fixing CVE-2024-26866 (kernel.org):
spi: lpspi: Avoid potential use-after-free in probe()
CVE entry at MITRE:
Linux SPI Documentation:
Conclusion
CVE-2024-26866 is a textbook example of how even minor memory management mismatches in the Linux kernel can lead to subtle but dangerous vulnerabilities. If you use SPI hardware on Linux, upgrade your kernel ASAP. Modern kernel driver writers: use “devm” helpers consistently for all resource management in probes!
Timeline
Published on: 04/17/2024 11:15:09 UTC
Last modified on: 01/27/2025 15:08:19 UTC