Medium [CVE-2026-74482] unlock i_mmap_rwsem before releasing after-split folios

In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed.

Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction.

But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.

A flaw was found in the Linux kernel's huge memory management (mm/huge_memory). A race condition exists in the `__folio_split()` function where the `i_mmap_rwsem` lock is released prematurely before all after-split folios are fully processed.

This allows a concurrent operation to free the inode while subsequent memory management operations attempt to access it, leading to a use-after-free vulnerability. This can result in system instability or a denial of service.