GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel hugetlbfs: fallocate hole-punch races page migration and corrupts page accounting

CVSS 7.8CVE-2025-40006Kernel, userspace & hypervisorcurated

Impact

remove_inode_single_folio() checked whether a hugetlb folio was still mapped without holding the folio lock. If migration converted the mapping to a migration entry at that moment, folio_mapped() returned false, the folio was never unmapped, migration was then forced to restore the mapping, and the page cache removal hit a BUG in filemap_unaccount_folio(). On GPU nodes this path is live traffic, not an edge case: hugetlbfs backs pinned host buffers for training jobs and DPDK/RDMA-style data paths, and NUMA balancing or compaction supplies the racing migration. The observed outcome is a kernel BUG and corrupted page accounting on a node that holds other tenants' jobs, so a crash costs the whole box, not one container.

Who can reach it

Local, authenticated: any user or tenant process that can fallocate a hole in a hugetlbfs file it owns, while the kernel concurrently migrates those huge pages. No special capability is named in the record; it needs hugetlbfs to be mounted and usable by the workload.

What to do

Pick up the stable kernel containing the fix that takes the folio lock before the mapped check (commits listed in the record) and reboot each affected node. There is no runtime mitigation short of denying workloads hugetlbfs access, which most training and HPC jobs will not tolerate. Plan this as a rolling drain-and-reboot across the fleet.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.