Linux kernel smaps: unlocked hugetlb PTE read races migration and hits BUG_ON

CVSS 4.7CVE-2025-39754Kernel, userspace & hypervisorcurated

Impact

smaps_hugetlb_range() reads a hugetlb PTE without holding the page-table lock. If page migration concurrently replaces the entry with a migration swap entry, pfn_swap_entry_to_page() hits a BUG_ON and the kernel panics. The trigger on the reading side is simply reading /proc/<pid>/smaps, which any local process - including a monitoring agent or any tenant in a container - can do. On a GPU node this is an unprivileged crash of the whole host, taking every co-tenant job with it, and nodes that run hugetlb-backed workloads alongside memory compaction or NUMA balancing are exactly where migration entries appear.

Who can reach it

Local, unauthenticated beyond having a shell or process on the node. Any tenant with a GPU pod can read smaps of a hugetlb-using process while the kernel migrates its pages; no root required.

What to do

Patch the kernel to the stable commits that take the ptl in smaps_hugetlb_range() and reboot each node. As an interim mitigation, restrict access to /proc/<pid>/smaps for untrusted processes (hidepid, container masking) - the crash needs a reader. The record lists stable commits but no named fixed release.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-39754 https://git.kernel.org/stable/c/09fc018f48871123ad5dbd7b03c956580232ed76 https://git.kernel.org/stable/c/b625883ccbcc2b57808db51d1375b1d7b9bcb3e5

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.