CVE-2026-90433 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
spi: oc-tiny: switch to managed controller allocation
The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base).
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.
This issue was found by an in-house static analysis tool.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's SPI oc-tiny driver stems from a critical mismatch in resource management lifecycles, specifically involving the allocation of the SPI controller and the registration of its interrupt handler. The core technical flaw arises because the controller was allocated using spi_alloc_host(), an unmanaged function that requires explicit deallocation by the driver developer, while the associated hardware interrupt was registered using devm_request_irq(), a managed resource request handled automatically by the device resource management subsystem. This discrepancy creates a race condition during the driver removal process where the timing of memory freeing does not align with the completion of pending asynchronous operations.
During the execution of the remove callback, spi_bitbang_stop() is invoked to stop ongoing transfers and unregister the controller from the SPI core. Immediately following this step, the code calls spi_controller_put(), which decrements the reference count on the controller object. If this count reaches zero, the kernel frees the memory associated with the controller structure as well as its embedded driver-private data structures. This private data includes the dev_id parameter passed to the interrupt handler, effectively invalidating any pointers contained within it that are required for normal operation.
The danger of this sequence lies in the asynchronous nature of hardware interrupts and their handling by the kernel's deferred work mechanisms. The managed resource framework ensures that free_irq() is called after the remove function returns, allowing time for pending or latched interrupt requests to be fully drained from the queue. However, because spi_controller_put() frees the memory before this draining process completes, any late-arriving or already-latched interrupt can trigger tiny_spi_irq(). When this occurs, the handler attempts to dereference pointers such as hw->base within the now-freed devdata structure. This results in a use-after-free condition, leading potentially to kernel panic, data corruption, or arbitrary code execution if an attacker can influence the timing of interrupts.
This vulnerability is classified under CWE-416: Use After Free, which describes situations where software continues to use memory after it has been freed, often resulting in unpredictable behavior and security breaches. From a tactical perspective related to MITRE ATT&CK, this flaw could be exploited by an attacker with local access who can trigger specific hardware states or interrupt patterns to induce the race condition, potentially escalating privileges or causing denial of service against the system running the kernel. The issue was originally detected through static analysis tools designed to identify such lifecycle mismatches in driver code before they manifest as runtime errors.
The remediation strategy involves aligning the resource management lifecycles by switching from spi_alloc_host() to devm_spi_alloc_host(). This managed allocation function ensures that the controller memory is freed only after all associated device resources, including the interrupt handler registered via devm_request_irq(), have been released in a Last-In-First-Out order. Consequently, free_irq() will drain any pending interrupts before the controller structure and its private data are deallocated, eliminating the window for use-after-free exploitation. Additionally, the explicit call to spi_controller_put() within the remove function is removed as it becomes redundant under managed allocation semantics. The probe error path is also simplified by using direct returns instead of manual cleanup calls, reducing code complexity and potential points of failure during initialization failures.