CVE-2026-64567 in Linux
Riassunto
di VulDB • 06/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
btrfs: rifiutare la cache dello spazio libero con un numero di voci superiore al numero di pagine
Durante il caricamento di una cache dello spazio libero v1, __load_free_space_cache() legge direttamente num_entries e num_bitmaps dall'intestazione su disco btrfs_free_space_header. Tale intestazione è memorizzata nel tree_root sotto una chiave di tipo 0, per la quale il tree-checker non prevede alcun caso specifico; pertanto, nessuno dei due conteggi viene convalidato prima che il caricamento si fidi dei valori letti.
Il ciclo di caricamento esegue num_entries iterazioni e mappatura della pagina successiva ogni volta che quella corrente termina, passando attraverso io_ctl_check_crc() -> io_ctl_map_page(), che effettua l'accesso a io_ctl->pages[io_ctl->index++]. Tuttavia, pages[] viene allocato in io_ctl_init() sulla base di i_size dell'inode della cache e non su num_entries:
num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); io_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS);
Pertanto, se num_entries dichiara più record di quanti ne possano essere contenuti nelle pagine disponibili, io_ctl->index supera il limite finale dell'array pages[]. Il lato scrittura non riscontra questo problema perché sia io_ctl_add_entry() che io_ctl_add_bitmap() si fermano una volta raggiunto il condizione io_ctl->index >= io_ctl->num_pages; il lato lettura, invece, non disponeva della stessa verifica.
Per innescare la vulnerabilità, è necessario prendere una cache pulita (con num_entries = <N> in questo scenario), impostare num_entries nell'intestazione a 0x10000 e correggere il checksum del leaf affinché superi comunque il tree-checker. L'inode della cache ha i_size = 65536, quindi num_pages è pari a 16 e pages[] è un array di puntatori (kmalloc-128) di dimensione 16. Il caricamento tenta ora di leggere 65536 voci; io_ctl->index arriva fino a 16 e si effettua una lettura oltre l'array in pages[16]:
BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork
free-space-cache.c:420 corrisponde a io_ctl_map_page(), inlineata in io_ctl_check_crc() alla riga 565, motivo per cui tale frame è quello indicato da KASAN. La slot fuori dai limiti viene quindi trattata come uno struct page e passata a crc32c(); la lettura non valida si trasforma così in un GP fault (General Protection Fault).
È stata aggiunta la verifica mancante in io_ctl_check_crc(), che rappresenta il punto di terminazione sia per il ciclo delle voci che per quello dei bitmap. Quando num_entries è eccessivamente grande, il caricamento fallisce come avviene per qualsiasi cache corrotta: __load_free_space_cache() la scarta e ricostruisce lo spazio libero a partire dall'extent tree; pertanto, una cache valida non viene mai rifiutata ingiustamente.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.