CVE-2026-99164 in Linux
Resumen
por VulDB • 2026-10-28
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
spi: imx: corregir corrupción del slab causada por buffers rebote DMA insuficientes
Desde el commit faa8e404ad8e ("spi: imx: soporte para longitud de ráfaga dinámica en modo ECSPI DMA"), el controlador asigna sus búferes privados TX/RX DMA con kzalloc(dma_len), donde dma_len solo se redondea hacia arriba a 4 bytes, pero los mapea, sincroniza y desmapea utilizando DMA_CACHE_ALIGNED_LEN(dma_len), es decir, redondeado al tamaño de la línea de caché. Como resultado, la API DMA opera en memoria más allá del final de la asignación.
Esto se observó en una plataforma i.MX8MP personalizada con un controlador CAN mcp251xfd bajo alta carga RPMSG, como una serie de advertencias refcount_t activadas desde rpmsg_recv_done() en virtio_rpmsg_bus:
refcount_t: adición sobre 0; use-after-free. refcount_t: desbordamiento por defecto (underflow); use-after-free. refcount_t: saturado; fuga de memoria.
Lo que finalmente conduce a un error "Unable to handle kernel paging request" (oops). Reproducir este problema tomó entre 30 minutos y aproximadamente 30 horas bajo la misma carga de trabajo.
Los puntos de observación por hardware en el recuento de referencias de una estructura rpmsg_endpoint mostraron que fue sobrescrito desde 2 a 1 por __pi_memcpy_generic() en el hilo irq/155-spi2.0. Además, se encontró que un "normal" rpmsg_recv_done() tomó 11µs +/-2µs desde su kref_get hasta kref_put. En el caso de error, la misma secuencia tardó aproximadamente 215µs +/-10µs. Basándose en esto, se utilizó una LLM (Large Language Model) para identificar la discrepancia de tamaño corregida aquí.
Asignar los búferes con DMA_CACHE_ALIGNED_LEN(dma_len) para que cubran toda la longitud mapeada, y utilizar la misma longitud para dma_sync_single_for_cpu() para mantener la coherencia con map y unmap.
Con este parche aplicado, la misma carga de trabajo se ejecutó durante más de 200 horas sin que el problema se reprodujera.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.