In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/huge_memory: unlock i_mmap_rwsem before releasing after-split folios<\/p>\n
__folio_split() keeps dereferencing the mapping after the split:
\nshmem_uncharge(mapping->host) and remap_page() while the folios are still
\nfrozen\/locked, and i_mmap_unlock_read(mapping) at the very end, after the
\nafter-split folios have been unlocked and freed.<\/p>\n
Nothing holds an inode reference across that. The split relies on @folio
\n— which the beyond-EOF drop loop never removes, as it starts at
\nfolio_next(folio) — staying locked and in the page cache to hold off
\neviction. But the unlock loop unlocks @folio before i_mmap_unlock_read()
\nruns. If the caller’s @lock_at is a tail beyond EOF, as memory_failure()
\npasses when splitting a poisoned tail of a shmem THP that reaches past
\ni_size during truncation, it too is gone from the page cache; so once
\n@folio is unlocked no locked, in-cache folio pins the inode, and a
\nconcurrent final iput() can evict and RCU-free it before
\ni_mmap_unlock_read() touches i_mmap_rwsem:<\/p>\n
BUG: KASAN: slab-use-after-free in __up_read+0x634\/0x790
\n i_mmap_unlock_read include\/linux\/fs.h:537 [inline]
\n __folio_split+0x732\/0x1640 mm\/huge_memory.c:4100
\n try_to_split_thp_page+0xab\/0x390 mm\/memory-failure.c:1675
\n memory_failure+0x1394\/0x26e0 mm\/memory-failure.c:2470<\/p>\n
Freed by task 4601:
\n shmem_free_in_core_inode+0x54\/0xb0 mm\/shmem.c:5177
\n evict+0x57f\/0xac0 fs\/inode.c:870<\/p>\n
Do every mapping dereference while @folio still pins the inode: drop
\ni_mmap_rwsem right after remap_page(), before the loop that unlocks and
\nfrees the after-split folios, and clear @mapping so the exit path does not
\nunlock it again. shmem_uncharge() and remap_page() already run before
\nthat point, so after this nothing past the unlock loop touches the inode
\nor the mapping.<\/p>\n
This is now a rule the split depends on, alongside keeping @folio frozen
\nuntil the page cache is updated: no inode or mapping dereference once the
\nafter-split folios start being unlocked.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
mm\/huge_memory: unlock i_mmap_rwsem before releasing after-split folios<\/p>\n
__folio_split() keeps dereferencing the mapping after the <\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-7476","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/7476","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7476"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7476"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7476"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}