Cloudanix VulnDB

CVE-2026-99164

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how certain Linux systems handle data transfers over SPI hardware can cause the whole machine to crash when the system is busy moving lots of messages.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

The spi-imx driver allocates private DMA TX/RX buffers using kzalloc rounded only to 4 bytes but maps/syncs/unmaps them using DMA_CACHE_ALIGNED_LEN, causing DMA operations to access memory beyond the allocated slab object and produce use-after-free corruption visible as refcount underflows and kernel paging faults.

Why it matters to the business

Systems using affected i.MX SPI controllers with DMA under sustained workloads can experience sudden kernel crashes or unpredictable memory corruption, leading to unplanned downtime and potential loss of data in flight on connected peripherals.

How an attack unfolds

An attacker with the ability to induce heavy SPI DMA traffic (for example via attached CAN or RPMSG devices) triggers repeated undersized buffer mappings; the resulting out-of-bounds writes corrupt adjacent slab objects such as rpmsg_endpoint refcounts, eventually causing a kernel oops after minutes to hours of operation.

How to fix it

Update the Linux kernel to a version containing the corrected allocation size using DMA_CACHE_ALIGNED_LEN(dma_len) for both allocation and dma_sync_single_for_cpu calls; rebuild and deploy the updated kernel image on all affected i.MX platforms.

How to confirm the fix worked

Confirm the source tree contains the allocation-size change, boot the new kernel under the previously triggering workload for at least 200 hours, and verify absence of refcount warnings or oops in dmesg and kernel logs.

Typical attack path

  1. Obtain local or hardware-adjacent access sufficient to drive SPI DMA traffic
  2. Sustain workload that exercises dynamic burst-length DMA paths in spi-imx
  3. Trigger repeated kzalloc(dma_len) allocations followed by DMA_CACHE_ALIGNED_LEN mappings
  4. Overwrite adjacent kernel objects (refcounts, pointers) via the buffer overrun
  5. Induce use-after-free or paging fault that crashes the kernel

How to detect it

Search kernel logs and dmesg for repeated refcount_t warnings (addition on 0, underflow, saturated) originating from rpmsg_recv_done or virtio_rpmsg_bus, followed by Unable to handle kernel paging request oops in irq threads handling spi2.0 or similar SPI DMA interrupts.

What your security team should do

  • Prioritize kernel updates on all i.MX-based devices within the next maintenance window
  • Add the corrected driver to automated build and test pipelines before wide rollout
  • Monitor kernel logs for refcount underflow or paging-request messages on production systems until patched

The record

In the Linux kernel, the following vulnerability has been resolved: spi: imx: fix slab corruption from undersized DMA bounce buffers Since commit faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode"), the driver allocates its private DMA TX/RX buffers with kzalloc(dma_len), where dma_len is only rounded up to 4 bytes, but maps, syncs and unmaps them with DMA_CACHE_ALIGNED_LEN(dma_len), i.e. rounded up to the cache line size. As a result, the DMA API operates on memory beyond the end of the allocation. This was observed on a custom i.MX8MP platform with an mcp251xfd CAN controller under heavy RPMSG load, as a series of refcount_t warnings triggered from rpmsg_recv_done() in virtio_rpmsg_bus: refcount_t: addition on 0; use-after-free. refcount_t: underflow; use-after-free. refcount_t: saturated; leaking memory. Leading finally to an "Unable to handle kernel paging request" oops. Reproducing this problem took between 30 minutes and roughly 30 hours under the same workload. Hardware watchpoints on the refcount of a struct rpmsg_endpoint showed it was overwritten from 2 to 1 by __pi_memcpy_generic() in the irq/155-spi2.0 thread. Additionally it was found that a "normal" rpmsg_recv_done() took 11µs +/-2µs from its kref_get to kref_put. In the error case the same sequence took about 215µs +/-10µs. Based on this, an LLM was used to identify the size mismatch fixed here. Allocate the buffers with DMA_CACHE_ALIGNED_LEN(dma_len) so they cover the full mapped length, and use the same length for dma_sync_single_for_cpu() to stay consistent with map and unmap. With this patch applied, the same workload ran for more than 200 hours without the problem reproducing.

Affected packages

Ecosystem Package Introduced Fixed