CVE-2026-90410 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
spi: davinci: switch to managed controller allocation
The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory.
Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns.
The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller.
This issue was found by an in-house static analysis tool.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel driver for the Texas Instruments DaVinci SPI peripheral contained a critical use-after-free vulnerability arising from improper resource management ordering during device removal and error handling paths. The core of the flaw lies in the mismatch between how the SPI controller structure was allocated and how its associated interrupt resources were managed. Specifically, the driver utilized spi_alloc_host to allocate the controller structure on the heap without attaching it to the kernel's device resource management framework. In contrast, the threaded IRQ handler for this controller was registered using devm_request_threaded_irq, which ties the lifecycle of the interrupt request to the device’s removal process through a release action that executes after the driver’s remove callback completes. This discrepancy created a race condition window where the SPI controller structure could be freed before the pending or late-arriving interrupts were fully drained and handled.
During normal operation, when the device is removed from the system, the kernel invokes the driver's remove function to clean up resources. In this vulnerable implementation, spi_bitbang_stop was called to unregister the controller logic, followed immediately by a manual call to spi_controller_put which decremented the reference count of the allocated structure. Since no other references were held at that moment, this action triggered the immediate deallocation of the davinci_spi data structure embedded within the SPI host controller. However, because the IRQ handler was registered with devm_request_threaded_irq, its cleanup routine free_irq does not execute until after the remove function returns to the core kernel code. Consequently, if a hardware interrupt occurred or remained latched in the peripheral between the moment of deallocation and the execution of free_irq, the interrupt service routine davinci_spi_irq would attempt to access memory that had already been returned to the system allocator. This constitutes a classic use-after-free scenario where dereferencing freed memory leads to undefined behavior, potential kernel panics, or arbitrary code execution if an attacker can control the contents of the reclaimed memory region through heap spraying techniques.
The operational impact of this vulnerability is severe due to its location within the kernel space and the nature of interrupt handling. An attacker with local access could potentially trigger device removal while simultaneously inducing high-frequency SPI activity or manipulating hardware states to ensure interrupts remain pending. The resulting use-after-free allows for memory corruption, which can be leveraged to escalate privileges from a standard user to root level by overwriting function pointers or control flow data structures in the kernel heap. Furthermore, because this issue was identified via static analysis rather than dynamic fuzzing, it suggests that similar resource management inconsistencies might exist elsewhere in the driver codebase where devm functions are mixed with manual allocation and deallocation calls without adhering to strict lifecycle ordering principles.
To mitigate this vulnerability, the fix involves refactoring the driver to strictly adhere to Linux kernel device resource management conventions by switching from spi_alloc_host to devm_spi_alloc_host. This change ensures that the SPI controller structure is tracked in a managed resource list with Last-In-First-Out semantics relative to other resources allocated during probe. By doing so, the framework guarantees that the IRQ handler's release action free_irq executes before the SPI controller memory is freed, thereby preventing any late interrupts from accessing invalid pointers. Additionally, the redundant manual call to spi_controller_put in the remove function was removed since the managed allocation handles deallocation automatically upon device detachment. This simplification also extends to the probe error path, which now uses direct returns instead of complex cleanup logic that could potentially leave resources in inconsistent states if an error occurs mid-initialization.
Further hardening measures were implemented regarding clock management and interrupt draining. The driver was updated to use devm_clk_get_enabled for acquiring the peripheral clock, ensuring proper integration with the device resource framework. However, because clocks are typically acquired before IRQs during probe, their release order under standard devm LIFO rules would result in the clock being disabled after the IRQ handler is freed. To prevent late interrupts from accessing registers of a controller whose clock has been gated off—a condition that can cause bus faults or undefined hardware behavior—the fix explicitly drains the interrupt using devm_free_irq before disabling the controller. This explicit draining ensures that any remaining pending interrupts are processed while the hardware remains active and accessible, eliminating the race window entirely. These changes align with industry best practices for kernel driver development as outlined in CWE-416 regarding use-after-free vulnerabilities and mitigate risks associated with improper resource cleanup sequences often categorized under ATT&CK techniques involving memory corruption for privilege escalation.