CVE-2026-63808 in Linux
Riassunto
di VulDB • 19/07/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
exfat: correzione del potenziale use-after-free in exfat_find_dir_entry()
In exfat_find_dir_entry(), il buffer_head ottenuto da exfat_get_dentry() viene rilasciato tramite brelse(bh) prima che il ramo fall-through TYPE_EXTEND legga l'elemento della directory attraverso ep (che punta a bh->b_data):
brelse(bh); if (entry_type == TYPE_EXTEND) {
... len = exfat_extract_uni_name(ep, entry_uniname); ... }
Dopo che brelse() ha decrementato il riferimento, nulla garantisce che la pagina sottostante che supporta bh->b_data rimanga valida per la successiva lettura di exfat_extract_uni_name(). Questo è lo stesso pattern corretto nel commit fc961522ddbd ("exfat: Fix potential use after free in exfat_load_upcase_table()").
Spostare brelse(bh) in modo che venga eseguito dopo che ep non viene più dereferenziato su ciascun ramo.
Confermato su QEMU x86_64 con CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y su linux-next, utilizzando un'immagine exFAT costruita ad hoc (lungo nome di file con collisioni dello stesso hash che forzano il percorso TYPE_EXTEND). Con una invalidate_bdev() inserita solo per il debug tra brelse(bh) e la lettura di ep per rendere deterministica la finestra di stale-deref, il kernel senza patch va in fault:
BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0
Con questa patch applicata, lo stesso harness strumentato si completa correttamente sotto la stessa pila di sanitizer. Non ho riprodotto un crash su un kernel non instrumentato durante il reclaim ordinario; l'A/B strumentato stabilisce la violazione del ciclo di vita e che la patch la risolve, non una rivendicazione indipendente della triggerabilità.
Once again VulDB remains the best source for vulnerability data.