Linux kernel THP split: use-after-free on the inode when memory-failure splits a shmem huge page

Impact

__folio_split() unlocks the after-split folios before it calls i_mmap_unlock_read(mapping). Nothing else holds an inode reference across that point, so when the split target is a tail beyond EOF — the case memory_failure() produces when it splits a poisoned tail of a shmem THP that reaches past i_size during truncation — a concurrent final iput() can evict and RCU-free the inode before i_mmap_rwsem is touched. KASAN reports a slab-use-after-free in __up_read; in production this is a host panic. The trigger is the kernel's own uncorrectable-memory-error handler, which on a dense GPU node with terabytes of DRAM is a routine event rather than a theoretical one: an ECC error that should have cost you one poisoned page instead takes down the node and every job on it. Treat this as a reliability fix on machines that run shmem/tmpfs-backed THP, not as a tenant-reachable escalation.

Who can reach it

Local only, and not reachable by an ordinary tenant as described. The path runs from memory_failure() — the kernel handling a real uncorrectable memory error — or from privileged hwpoison injection (MADV_HWPOISON, hwpoison debugfs), racing a concurrent truncate/unlink of the shmem file. The record describes no unprivileged trigger.

What to do

Update to a stable kernel that drops i_mmap_rwsem right after remap_page(), before the folios are unlocked. Kernel change: drain and reboot each node. There is no configuration mitigation short of disabling THP for shmem, which carries its own performance cost on large-memory GPU hosts and is a heavier decision than the reboot.

References