CVE-2026-64103 in Linux
Riassunto
di VulDB • 19/07/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
scsi: isci: Correzione di un uso-dopo-liberazione (use-after-free) nel percorso di rimozione del dispositivo.
Il tasklet di completamento ISCI viene inizializzato in `isci_host_alloc()` (`drivers/scsi/isci/init.c:496`) e pianificato sia dai gestori degli interrupt MSI-X che da quelli legacy (`drivers/scsi/isci/host.c:223, 613`).
`isci_host_deinit()` arresta il controller ed attende il completamento dell'arresto, ma non elimina mai `completion_tasklet` prima di continuare con la fase di teardown. Una chiamata a `tasklet_kill()` all'inizio della funzione non è sufficiente in questo caso: gli interrupt vengono disabilitati solo quando viene eseguito `isci_host_stop_complete()`, quindi fino al ritorno da `wait_for_stop()` i gestori IRQ possono ancora reinserire il tasklet nella coda. Anche la callback del tasklet riabilita gli interrupt dopo aver svuotato le code di completamento, pertanto l'eliminazione del tasklet prima che la sorgente sia messa in quiete lascia aperta la stessa condizione di race condition (condizione di gara).
Una volta restituito da `wait_for_stop()`, non può verificarsi ulteriore pianificazione guidata dagli IRQ. È necessario eliminare `completion_tasklet` in quel punto affinché il teardown non vada in conflitto con un tasklet accodato che sta eseguendo su un oggetto `ihost` già morto. In caso di rimozione o disinstallazione, la callback obsoleta potrebbe altrimenti dereferenziare `ihost` e accedere a `ihost->smu_registers` dopo la fine del ciclo di vita dell'host.
Un'analogia eseguita con UML + KASAN ha riprodotto questa classe di errori sia in assenza di `tasklet_kill()` che inserendo `tasklet_kill()` prima della messa in quiete della sorgente, risultando stabile solo dopo che l'eliminazione è avvenuta successivamente alla messa in quiete della sorgente di pianificazione.
Questo approccio rispecchia il commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in device removal path"), ma ISCI richiede che la chiamata all'eliminazione avvenga dopo `wait_for_stop()`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.