CVE-2026-31648

What it actually does

This Linux kernel memory-management flaw is an integer underflow/overflow condition in filemap_map_pages() during fault-around mapping of file-backed pages. A race between mapping a large folio and a concurrent file-size shrink can cause the kernel to calculate an invalid nr_pages value and map beyond the bounds of the folio. That can corrupt page metadata such as mapcount/reference-count state for pages outside the intended folio, leading to kernel memory corruption, crashes, and potentially local privilege escalation. The CVSS vector indicates local access with low complexity and low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation can allow a low-privileged local user or compromised workload to destabilize a Linux host, crash the kernel, corrupt memory, or potentially gain elevated privileges. This is most relevant to multi-user Linux systems, container hosts, build servers, shared compute platforms, and environments where untrusted users or workloads can execute local code. It is not listed in CISA KEV, has no known ransomware use, no reported public exploit maturity, and has a low EPSS score that has remained flat over 30 days, so broad internet-scale exploitation is not currently indicated; however, kernel local privilege escalation bugs can become high priority quickly once exploit code appears.

How an attack unfolds

An attacker first needs the ability to run code locally on an affected Linux system. They would trigger repeated file-backed memory mappings while concurrently causing file-size changes, such as truncation or setattr operations, to win the race between filemap_map_pages() selecting a folio and later recalculating the file end. If the race is won, the kernel may compute an overflowing nr_pages value and attempt to install page table mappings beyond the large folio's actual size. This can corrupt adjacent page metadata and produce warnings such as Bad page state, nonzero mapcount with zero refcount, or faults in folio_add_file_rmap_ptes(), set_pte_range(), and filemap_map_pages(). A reliable exploit would attempt to shape memory layout and repeated race timing to convert this corruption into privilege escalation; less controlled triggering may simply crash the system.

How to fix it

Upgrade to a Linux kernel release that includes the upstream fix moving the end_pgoff calculation before next_uptodate_folio() in filemap_map_pages(), or apply the vendor backport for the affected distribution kernel. Because no product-specific fixed versions were provided, use the relevant Linux distribution advisory and kernel package changelog to identify the corrected kernel build for each platform. After updating, reboot into the patched kernel and remove or de-prioritize boot entries for vulnerable kernels where operationally feasible. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, hardening container escape paths, disabling or limiting unprivileged user namespaces where feasible, enforcing least privilege, and monitoring for kernel crash signatures. These mitigations reduce exploit opportunity but do not correct the underlying kernel memory corruption flaw.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated by checking uname -a or equivalent fleet inventory after reboot. Validate against the Linux distribution security advisory or kernel changelog for the fix to filemap_map_pages() / nr_pages calculation overflow. Review /boot and package-manager state to ensure systems are not still booting vulnerable kernels. Where source validation is used, confirm the kernel contains the change that calculates end_pgoff before next_uptodate_folio() in mm/filemap.c. Operational validation should include checking that no new kernel logs show Bad page state, VM_WARN_ON_FOLIO, folio_add_file_rmap_ptes(), set_pte_range(), or filemap_map_pages() warnings under normal workload. Avoid running proof-of-concept stress tests on production systems because failed attempts may crash the host.

Typical attack path

1. Gain local code execution as an unprivileged user or inside a workload/container that can exercise file-backed mmap behavior.
2. Create or access files on a filesystem that supports the relevant file-backed page-cache behavior, such as common Linux filesystems using large folios.
3. Repeatedly mmap file ranges while another thread or process shrinks/truncates the same file or changes inode size.
4. Race the kernel so filemap_map_pages() works with a folio selected under one file size but calculates the mapping range after a smaller file size is visible.
5. Trigger nr_pages overflow/underflow and force set_pte_range() or related routines to map beyond the large folio boundary.
6. Cause kernel page metadata corruption, leading to a crash or, with exploit engineering, potential privilege escalation.

How to detect it

Detection should focus on evidence of attempted triggering and resulting kernel memory corruption because no network indicator is expected for this local vulnerability. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, pstore, kdump/vmcore, and EDR telemetry for page-cache, folio, and page-state warnings. Look for kernel messages mentioning Bad page state, nonzero mapcount, refcount:0 with mapcount:1, VM_WARN_ON_FOLIO, folio_add_file_rmap_ptes, set_pte_range, filemap_map_folio_range, filemap_map_pages, do_fault_around, ext4_setattr, truncate_pagecache, and stress-style mmap/truncation activity. Correlate such events with local process execution, recently created mmap/truncate stress tools, suspicious binaries in temporary directories, abnormal fork/thread bursts, and privilege changes shortly after kernel warnings. Because the issue is local, also examine auditd, process accounting, shell history where available, container runtime logs, and EDR process trees for untrusted users repeatedly invoking mmap-heavy, mlock-heavy, truncate-heavy, or stress-ng-like workloads. A kernel panic or reboot preceded by these log patterns on an unpatched kernel should be investigated as possible exploitation even if no stable privilege escalation artifact is found.

• Bad page state
• nonzero mapcount
• refcount:0 mapcount:1
• VM_WARN_ON_FOLIO
• folio_add_file_rmap_ptes
• set_pte_range
• filemap_map_folio_range
• filemap_map_pages
• do_fault_around
• next_uptodate_folio
• truncate_pagecache
• ext4_setattr
• stress-ng-mmaptorture
• stress-ng-mlock
• stress-ng-env
• page dumped because: nonzero mapcount
• page dumped because: VM_WARN_ON_FOLIO
• BUG: Bad page state in process
• WARNING: ./include/linux/rmap.h

What your security team should do

• Prioritize patching shared, multi-tenant, developer, CI/CD, container-host, VDI, HPC, and internet-facing service hosts where local code execution by lower-privileged users is plausible.
• Inventory Linux kernel versions across the fleet and map them to vendor advisories because fixed package versions vary by distribution and no universal fixed version was provided.
• Schedule reboots after kernel updates and verify the active running kernel is the patched one.
• Monitor for kernel log signatures associated with this bug, especially Bad page state, nonzero mapcount, VM_WARN_ON_FOLIO, folio_add_file_rmap_ptes, set_pte_range, and filemap_map_pages.
• Treat unexplained kernel crashes or page-state corruption on affected kernels as potential exploitation or attempted exploitation, particularly on systems allowing untrusted local workloads.
• Until patched, limit local interactive access, constrain untrusted containers, disable unprivileged user namespaces where feasible, and apply mandatory access controls such as SELinux or AppArmor.
• Track exploit maturity and KEV status; reassess urgency if public exploit code, threat actor use, or ransomware adoption emerges.