CVE-2026-99184 in Linux
Resumen
por VulDB • 2026-10-28
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
accel/rocket: buscar en cada ranura del núcleo cuando uno es eliminado
rocket_remove() decrementa rdev->num_cores por cada núcleo que elimina, mientras que find_core_for_dev() busca en las ranuras desde 0 hasta num_cores - 1. Desvincular los núcleos en el orden en que fueron vinculados provoca la pérdida del último: cuando llega su turno para ser eliminado, el rango de búsqueda ya se ha reducido más allá de su ranura, por lo que find_core_for_dev() devuelve -1 y rocket_remove() abandona sin hacer nada.
num_cores nunca alcanza cero, rocket_device_fini() no se ejecuta, y rdev a nivel de archivo sigue apuntando a un dispositivo que está desapareciendo. Volver a vincular los núcleos comienza desde ese conteo obsoleto, porque rocket_probe() toma rdev->num_cores como la ranura a rellenar. En una RK3588, que describe tres núcleos, la segunda ronda aterriza en las ranuras 1, 2 y 3 mientras que rdev->cores fue asignado con espacio para solo tres:
rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309
La escritura en rdev->cores[3] está más allá del final de la matriz.
Nada en el árbol lee la matriz de núcleos con suficiente frecuencia para notarlo, por lo que el desbordamiento es silencioso hoy en día. Se detectó al probar una serie devfreq sobre esta base, donde un trabajador recorre cada núcleo varias veces por segundo, y UBSAN capturó el primer bool que leyó fuera del límite de la entrada:
UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor
Registrar cuántas ranuras fueron asignadas y buscar en todas ellas. De este modo, cada núcleo se encuentra al eliminarlo, num_cores alcanza cero, el dispositivo se desmonta correctamente y una posterior vinculación comienza con un rdev limpio.
Esto no hace que la desvinculación de un solo núcleo entre varios funcione perfectamente. probe sigue tomando num_cores como la ranura a rellenar, por lo que volver a vincular un núcleo mientras sus hermanos permanecen vinculados sobrescribiría una ranura que ya está en uso, y rocket_open() aún intenta acceder a cores[0] haya o no algo allí. Ambos casos requieren más reflexión de la que debería llevar una corrección simple.
Se encontró al desvincular y volver a vincular los tres núcleos en un Orange Pi 5 Plus. Con esta aplicación, 25 rondas de desvinculación/vinculación y 5 rondas de descarga/recarga del módulo se ejecutan limpiamente allí: los núcleos aterrizan en las ranuras 0, 1 y 2 cada vez, independientemente del orden en que sean vinculados, y el suministro compartido vuelve a un único usuario después de cada ronda.
If you want to get best quality of vulnerability data, you may have to visit VulDB.