GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/filemap: nr_pages overflow in fault-around maps past the end of a large folio

CVSS 7.8CVE-2026-31648Kernel, userspace & hypervisorcurated

Impact

A race between filemap_map_pages() holding a folio with a stale inode->i_size and a concurrent truncate (ext4_setattr) lets nr_pages overflow, so set_pte_range() installs PTEs beyond the large folio's size. That corrupts page fields - page->_mapcount among them - on pages that do not belong to the folio, which surfaces later as "Bad page state" and nonzero-mapcount splats far from the original fault. The reporter hit it with stress-ng on arm64 on 7.0-rc3. Cross-folio page metadata corruption on a host kernel is a privilege escalation candidate and, more commonly, an unexplained crash on a node that then has to be drained and rebooted. It is reachable from ordinary file-backed mmap plus truncate, so any tenant with a writable filesystem can drive the pattern.

Who can reach it

Local, unprivileged: a process that mmaps a file-backed large folio and races a truncate on the same file. No capability required; both halves are standard syscalls available inside a container with a writable mount.

What to do

Update the host kernel to a build carrying the stable fix commits below and reboot each node. No mitigation short of patching is identified in the record - the overflow is in the fault-around path that ordinary file mappings use.

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.