Linux kernel hugetlbfs: list corruption in reservation top-up can link a kernel-stack address into MM state

Impact

When a hugetlbfs file is mapped MAP_SHARED by more than one process, the reservation cache top-up drops resv->lock around a GFP_KERNEL allocation and splices the new entries with list_splice(), which leaves the stack-local head pointing at an entry now owned by resv->region_cache. Concurrent region_chg/region_add/region_del traffic on the same shared resv_map can consume cache entries during that window and force a second loop iteration, which then does list_add() on the stale head. With CONFIG_DEBUG_LIST the kernel BUGs immediately; without it a kernel-stack address is silently linked into resv->region_cache and becomes a later use-after-free. The reporter saw this as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was also mapped by an SPDK/DPDK vhost-user target. On a GPU node the same sharing pattern is routine (large-page-backed VMs, DPDK-style dataplanes, HPC jobs on a shared hugetlbfs file), and the failure mode is losing the whole node and every tenant on it.

Who can reach it

Local and unprivileged: any process that can mmap a hugetlbfs file another process is concurrently mapping or unmapping. No capability beyond access to the hugetlbfs mount, and no remote path. It is a race, so triggering it is timing-dependent rather than deterministic.

What to do

Take a stable kernel carrying the list_splice_init() fix (five stable branches have it; pick the one matching your tree from the commits below) or your distro's equivalent update. A kernel change means drain the node and reboot it — there is no module reload or runtime toggle here, and the only mitigation short of patching is to stop sharing a single hugetlbfs file between processes, which is usually the point of the deployment.

References