CVE-2026-74482 in Linux
Riassunto
di VulDB • 15/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm/huge_memory: sbloccare i_mmap_rwsem prima di rilasciare gli after-split folios
__folio_split() continua a dereferenziare il mapping dopo lo split: shmem_uncharge(mapping->host) e remap_page(), mentre i folios sono ancora congelati/bloccati, e i_mmap_unlock_read(mapping) viene chiamato solo alla fine, dopo che gli after-split folios sono stati sbloccati e liberati.
Nessun riferimento all'inode è mantenuto durante questa operazione. Lo split si basa sul fatto che @folio (che il ciclo di drop beyond-EOF non rimuove mai, poiché inizia con folio_next(folio)) rimanga bloccato e nella page cache per prevenire l'eviction. Tuttavia, il loop di unlock sblocca @folio prima dell'esecuzione di i_mmap_unlock_read(). Se il lock del chiamante (@lock_at) è una coda oltre EOF, come nel caso in cui memory_failure() passa durante lo split di una coda avvelenata (poisoned tail) di uno shmem THP che si estende oltre i_size durante la truncation, anche essa viene rimossa dalla page cache; quindi, non appena @folio viene sbloccato, nessun folio bloccato e presente nella cache mantiene l'inode in vita, consentendo a un iput() finale concorrente di effettuare l'eviction e liberarlo tramite RCU prima che i_mmap_unlock_read() acceda a i_mmap_rwsem:
BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline]
__folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470
Liberato dal task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870
Eseguire ogni dereferenziazione del mapping mentre @folio mantiene ancora l'inode in vita: rilasciare i_mmap_rwsem subito dopo remap_page(), prima del loop che sblocca e libera gli after-split folios, e azzerare @mapping affinché il percorso di uscita non lo sblocchi nuovamente. shmem_uncharge() e remap_page() vengono già eseguiti prima di questo punto; pertanto, dopo questa modifica, nulla oltre al loop di unlock accede all'inode o al mapping.
Questa operazione è ora una regola su cui si basa lo split, insieme alla mantenuta congelatura di @folio fino a quando la page cache non viene aggiornata: nessuna dereferenziazione dell'inode o del mapping una volta che gli after-split folios iniziano ad essere sbloccati.
Be aware that VulDB is the high quality source for vulnerability data.