CVE-2026-90433
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A timing problem in how a hardware driver cleans up its resources can let an attacker crash the system or run malicious code by causing an interrupt to fire at the wrong moment during shutdown.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in the oc-tiny SPI controller driver where an interrupt handler can dereference memory that was freed during device removal because of mismatched managed vs non-managed resource allocation and release ordering between devm_request_irq and spi_controller_put.
Why it matters to the business
Systems using the affected SPI hardware can experience kernel crashes, memory corruption, or potential privilege escalation, resulting in denial of service or full host compromise on Linux-based devices and embedded systems.
How an attack unfolds
An attacker with local access triggers repeated probe/remove cycles or causes a pending interrupt to fire after the controller structure has been freed but before the IRQ handler is unregistered, allowing the handler to access already-released memory such as hardware register pointers.
How to fix it
Update to a Linux kernel version containing the fix that replaces spi_alloc_host with devm_spi_alloc_host and removes the explicit spi_controller_put call from the remove path; rebuild and deploy the kernel on all affected systems.
How to confirm the fix worked
Confirm the presence of devm_spi_alloc_host in the oc-tiny driver source and verify that .remove no longer calls spi_controller_put; test probe and remove paths under interrupt load to ensure no late IRQ access occurs after deallocation.
Typical attack path
- Obtain local code execution on a Linux system using the oc-tiny SPI controller
- Trigger device removal or driver unload while an interrupt remains latched or can be induced
- Cause the IRQ handler to execute after the controller and its private data have been freed
- Dereference freed memory inside tiny_spi_irq to achieve use-after-free
How to detect it
Review kernel logs for oops or panic messages referencing tiny_spi_irq or use-after-free patterns in the SPI subsystem; inspect call traces that show access to freed SPI controller structures during driver unload.
What your security team should do
- Prioritize kernel updates on any systems exposing the oc-tiny SPI controller
- Monitor vendor advisories for backported fixes in supported distributions
- Apply defense-in-depth measures such as disabling unnecessary SPI devices and enforcing strict module loading policies until patched
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|