Cloudanix VulnDB

CVE-2026-90410

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing mistake when unplugging certain SPI hardware in the Linux kernel can let an interrupt touch memory that has already been freed, risking crashes or attacks on affected devices.

Chainable
Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in davinci_spi_irq() handler: non-managed spi_alloc_host() plus devm_request_threaded_irq() allows a late interrupt to dereference the embedded davinci_spi structure after spi_controller_put() has freed it during .remove().

Why it matters to the business

Kernel panic, privilege escalation, or denial of service on embedded systems using the Davinci SPI controller; low ecosystem prevalence limits blast radius but requires kernel updates on affected devices.

How an attack unfolds

An attacker with local access triggers module unload or device removal while a pending or latched interrupt can still fire; the handler then executes against already-freed memory, enabling controlled read/write or crash.

How to fix it

Apply the upstream fix: switch to devm_spi_alloc_host(), remove the explicit spi_controller_put() call, use devm_free_irq() before clock disable, and rebuild the kernel; no backported fixed versions are listed.

How to confirm the fix worked

Confirm the commit introducing devm_spi_alloc_host() and devm_free_irq() ordering is present in the running kernel; inspect /proc/config.gz or kernel source for the corrected probe/remove paths.

Typical attack path

  1. Obtain local code execution or physical access to the target system
  2. Unload the davinci_spi module or trigger .remove() on the SPI controller
  3. Arrange for a latched interrupt to remain pending across removal
  4. Interrupt handler dereferences freed davinci_spi dev_id structure

How to detect it

Search kernel logs for oops/panic traces referencing davinci_spi_irq or spi_bitbang_stop around module unload events; examine dmesg and serial console output for use-after-free warnings triggered by SPI controller removal.

What your security team should do

  • Prioritize kernel updates on any device exposing the davinci SPI controller
  • Audit embedded Linux images for the vulnerable spi-davinci driver
  • Enable kernel hardening options such as CONFIG_SLAB_FREELIST_RANDOM and panic_on_oops
  • Monitor for future stable kernel releases containing this change

The record

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.

Affected packages

Ecosystem Package Introduced Fixed