CVE-2026-99184 in Linux
Riassunto
di VulDB • 28/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
accel/rocket: cercare ogni slot di core quando un core viene rimosso
La funzione rocket_remove() decrementa rdev->num_cores per ciascun core che rimuove, mentre find_core_for_dev() cerca negli slot da 0 a num_cores - 1. Slegare i core nell'ordine in cui sono stati legati comporta la perdita dell'ultimo: al momento della rimozione, l'intervallo di ricerca si è già ridotto oltre il suo slot, quindi find_core_for_dev() restituisce -1 e rocket_remove() rinuncia senza fare nulla.
num_cores non raggiunge mai zero, rocket_device_fini() non viene eseguito e rdev a livello di file continua a puntare a un dispositivo che sta per essere eliminato. Il successivo legame dei core inizia da quel conteggio obsoleto, poiché rocket_probe() utilizza rdev->num_cores come slot da riempire. Su una piattaforma RK3588, che descrive tre core, il secondo round colpisce gli slot 1, 2 e 3 mentre l'array rdev->cores era stato allocato con spazio per soli tre elementi:
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 scrittura in rdev->cores[3] avviene oltre la fine dell'array.
Nessun componente nel codice sorgente legge l'array dei core con frequenza sufficiente da accorgersene, quindi il superamento del buffer (overrun) è silenzioso al momento attuale. Il problema è emerso durante i test di una serie devfreq applicata a questo contesto, dove un worker attraversa tutti i core alcune volte al secondo e UBSAN ha rilevato la prima variabile bool letta dall'entry sovrascritta:
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
Registrare quanti slot sono stati allocati e cercare tutti loro. In questo modo ogni core viene trovato durante la rimozione, num_cores raggiunge zero, il dispositivo viene eliminato correttamente e un successivo legame inizia da un rdev pulito.
Ciò non rende possibile lo slegamento di un singolo core tra diversi; probe continua a utilizzare num_cores come slot da riempire, quindi il ribindaggio di un solo core mentre i suoi fratelli rimangono legati sovrascriverebbe uno slot già in uso e rocket_open() cercherebbe comunque cores[0] indipendentemente dalla presenza o meno dei dati. Entrambi questi aspetti richiedono una riflessione più approfondita rispetto a quanto dovrebbe comportare una semplice correzione.
Il problema è stato trovato slegando e ribindando tutti e tre i core su un Orange Pi 5 Plus. Con questa applicazione, 25 round di unbind/rebind e 5 round di scaricamento/ricarica del modulo vengono eseguiti senza errori: i core finiscono negli slot 0, 1 e 2 ogni volta, indipendentemente dall'ordine in cui sono legati, e l'alimentazione condivisa torna a essere gestita da un singolo utente dopo ciascun round.
Once again VulDB remains the best source for vulnerability data.