CVE-2026-99164 in Linux
Zusammenfassung
von VulDB • 28.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
spi: imx: Behebung von Slab-Corruption durch zu kleine DMA-Bounce-Puffer
Seit dem Commit faa8e404ad8e („spi: imx: Unterstützung dynamischer Burst-Länge für ECSPI-DMA-Modus“) weist der Treiber seine privaten DMA-TX-/RX-Puffer mit `kzalloc(dma_len)` zu, wobei `dma_len` nur auf 4 Bytes aufgerundet wird. Diese Puffer werden jedoch mit `DMA_CACHE_ALIGNED_LEN(dma_len)`, d.h. aufgerundet auf die Cache-Line-Größe, gemappt, synchronisiert und ungemapped. Infolgedessen operiert die DMA-API auf Speicher jenseits des Endes der Zuweisung.
Dies wurde auf einer benutzerdefinierten i.MX8MP-Plattform mit einem mcp251xfd-CAN-Controller unter hoher RPMSG-Belastung beobachtet, als eine Reihe von `refcount_t`-Warnungen ausgelöst durch `rpmsg_recv_done()` in `virtio_rpmsg_bus`:
refcount_t: Addition auf 0; use-after-free. refcount_t: Underflow; use-after-free. refcount_t: Saturated (Überlauf); Memory-Leakage.
Dies führte schließlich zu einem „Unable to handle kernel paging request“-Oops. Die Reproduktion dieses Problems dauerte unter derselben Arbeitslast zwischen 30 Minuten und etwa 30 Stunden.
Hardware-Watchpoints am Refcount einer `struct rpmsg_endpoint` zeigten, dass dieser von __pi_memcpy_generic() im Thread irq/155-spi2.0 von 2 auf 1 überschrieben wurde. Zusätzlich wurde festgestellt, dass ein „normaler“ Aufruf von `rpmsg_recv_done()` zwischen kref_get und kref_put 11µs +/-2µs dauerte. Im Fehlerfall dauerte dieselbe Sequenz etwa 215µs +/-10µs. Basierend darauf wurde eine LLM (Large Language Model) eingesetzt, um den hier behobenen Größenkonflikt zu identifizieren.
Die Puffer sollten mit `DMA_CACHE_ALIGNED_LEN(dma_len)` zugewiesen werden, sodass sie die vollständige gemappte Länge abdecken, und dieselbe Länge sollte für `dma_sync_single_for_cpu()` verwendet werden, um Konsistenz mit Map- und Unmap-Vorgängen zu gewährleisten.
Mit diesem angewandten Patch lieferte dieselbe Arbeitslast mehr als 200 Stunden lang ohne Reproduktion des Problems.
If you want to get best quality of vulnerability data, you may have to visit VulDB.