CVE-2026-74482 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
mm/huge_memory: i_mmap_rwsem entsperren, bevor nach dem Aufteilen von Folios freigegeben wird
__folio_split() dereferenziert die Zuordnung (mapping) weiterhin nach der Teilung: shmem_uncharge(mapping->host) und remap_page(), während die Folios noch eingefroren/gesperrt sind, sowie i_mmap_unlock_read(mapping) ganz am Ende, nachdem die Folios nach dem Aufteilen entsperrt und freigegeben wurden.
Es hält keine Inode-Referenz über diesen Zeitraum hinweg aufrecht. Die Teilung verlässt sich darauf, dass @folio – das in der Schleife zum Herunterzählen jenseits von EOF niemals entfernt wird, da sie bei folio_next(folio) beginnt –, gesperrt bleibt und im Seiten-Cache vorliegt, um ein Ausblenden (Eviction) zu verhindern. Die Entsperr-Schleife entsperrt jedoch @folio, bevor i_mmap_unlock_read() ausgeführt wird. Wenn die @lock_at des Aufrufers eine Tail-Position jenseits von EOF ist, wie es memory_failure() beim Aufteilen eines vergifteten Tails eines shmem THP (Transparent Huge Page) tut, das während der Trunkation über i_size hinausreicht, befindet er sich ebenfalls nicht mehr im Seiten-Cache; sobald also @folio entsperrt wurde, sperrt kein gesperrtes, im Cache befindliches Folio den Inode, und ein gleichzeitiger finaler iput() kann ihn ausblenden und per RCU freigeben (RCU-free), bevor i_mmap_unlock_read() auf i_mmap_rwsem zugreift:
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
Freigegeben von Task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870
Führen Sie jede Dereferenzierung der Zuordnung durch, während @folio den Inode noch sperrt: Geben Sie i_mmap_rwsem direkt nach remap_page() frei, vor der Schleife, die die Folios nach dem Aufteilen entsperrt und freigibt, und setzen Sie @mapping auf NULL (clear), damit der Exit-Pfad ihn nicht erneut entsperren kann. shmem_uncharge() und remap_page() werden bereits vor diesem Punkt ausgeführt; daher greift nach dieser Änderung nichts mehr jenseits der Entsperr-Schleife auf den Inode oder die Zuordnung zu.
Dies ist nun eine Regel, von der die Teilung abhängt, neben dem Einfrieren von @folio bis zur Aktualisierung des Seiten-Caches: Keine Dereferenzierung eines Inodes oder einer Zuordnung, sobald das Entsperren der Folios nach dem Aufteilen beginnt.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.