CVE-2026-90433: spi: oc-tiny: switch to managed controller allocation
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 spiallochost() while the interrupt is registered with devmrequestirq(). During removal, spibitbangstop() only unregisters the controller; the subsequent spicontrollerput() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's devid. The devmrequestirq() release action (freeirq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tinyspiirq() and dereference already-freed memory (e.g. hw->base).
Switch to devmspiallochost() so that the devres LIFO order releases the controller only after freeirq() has drained the handler, and drop the now-redundant spicontrollerput() from .remove(). The probe error path is simplified to direct returns.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the spi oc-tiny driver to allocate the SPI controller using devm_spi_alloc_host() so that devres LIFO releases occur after resources like devm_request_irq() have drained the IRQ handler; this prevents interrupts from reaching tiny_spi_irq() after .remove() returns.
Linux kernel Controller allocation function = Use devm_spi_alloc_host() instead of spi_alloc_host() - Configuration
In the spi oc-tiny driver, drop the now-redundant spi_controller_put() call from the .remove() path because devm_spi_alloc_host() will free the controller after free_irq() has drained the handler.
spi oc-tiny driver Remove-time controller release = Remove redundant spi_controller_put() from .remove()
Event History
Frequently Asked Questions
When can this flaw be triggered?
It can be triggered during driver removal if a late or latched interrupt reaches the oc-tiny SPI IRQ handler after the SPI controller and its driver-private data have been freed.
What systems are exposed?
Systems using the Linux kernel oc-tiny SPI driver are exposed when that driver is removed while its interrupt can still be delivered. The issue is tied to the driver's controller allocation and IRQ cleanup ordering.
What is the consequence of a successful trigger?
The IRQ handler can dereference freed driver-private memory, including the hardware base pointer. This is a use-after-free condition in the kernel.
What change resolves the cleanup ordering problem?
The resolved implementation allocates the SPI controller with managed allocation so that the managed IRQ release action drains the handler before the controller is released. It also removes the explicit controller put operation from the remove path.