Look up another CVE · open CVE-2026-31648 in the interactive tracker
CVE-2026-31648
mm: filemap: fix nr_pages calculation overflow in filemap_map_pages()
Published 2026-04-24 (6 months ago) by the Linux kernel CNA. Subsystem mm. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-31648 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6238-1 · 2026-04-30 · text | 6.12.85-1 | Update the kernel and reboot. DSA-6238-1 shipped the fix on 2026-04-30, in 6.12.85-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.19.13-1 | Update the kernel and reboot. Fixed in 6.19.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.19.13-1 | Update the kernel and reboot. Fixed in 6.19.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as "Bad page state": " [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff) [ 734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000 [ 734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000 [ 734.496442] page dumped because: nonzero mapcount " After analyzing this page’s state, it is hard to understand why the mapcount is not 0 while the refcount is 0, since this page is not where the issue first occurred. By enabling the CONFIG_DEBUG_VM config, I can reproduce the crash as well and captured the first warning where the issue appears: " [ 734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0 [ 734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 734.469315] memcg:ffff000807a8ec00 [ 734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540" [ 734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff) ...... [ 734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio) [ 734.469390] ------------[ cut here ]------------ [ 734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468, CPU#90: stress-ng-mlock/9430 [ 734.469551] folio_add_file_rmap_ptes+0x3b8/0x468 (P) [ 734.469555] set_pte_range+0xd8/0x2f8 [ 734.469566] filemap_map_folio_range+0x190/0x400 [ 734.469579] filemap_map_pages+0x348/0x638 [ 734.469583] do_fault_around+0x140/0x198 ...... [ 734.469640] el0t_64_sync+0x184/0x188 " The code that triggers the warning is: "VM_WARN_ON_FOLIO(page_folio(page + nr_pages - 1) != folio, folio)", which indicates that set_pte_range() tried to map beyond the large folio’s size. By adding more debug information, I found that 'nr_pages' had overflowed in filemap_map_pages(), causing set_pte_range() to establish mappings for a range exceeding the folio size, potentially corrupting fields of pages that do not belong to this folio (e.g., page->_mapcount). After above analysis, I think the possible race is as follows: CPU 0 CPU 1 filemap_map_pages() ext4_setattr() //get and lock folio with old inode->i_size next_uptodate_folio() ....... //shrink the inode->i_size i_size_write(inode, attr->ia_size); //calculate the end_pgoff with the new inode->i_size file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; end_pgoff = min(end_pgoff, file_end); ...... //nr_pages can be overflowed, cause xas.xa_index > end_pgoff end = folio_next_index(folio) - 1; nr_pages = min(end, end_pgoff) - xas.xa_index + 1; ...... //map large folio filemap_map_folio_range() ...... //truncate folios truncate_pagecache(inode, inode->i_size); To fix this issue, move the 'end_pgoff' calculation before next_uptodate_folio(), so the retrieved folio stays consistent with the file end to avoid ---truncated---
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
mm/filemap.c
- What this is
- PAGE CACHEMAINTAINERS section matched on mm/filemap.c · linux-fsdevel@vger.kernel.org · Supported
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-04-24 (6 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- mm
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.6.117 | 6.6.135 | 88591194df73 |
| 6.12 | 6.12.82 | 633ab680c405 |
| 6.12 | 6.18.23 | 576543bedd61 |
| 6.12 | 6.19.13 | 9316a820b9aa |
| 6.12 | 7.0 | f58df566524e |
| 6.1.159 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DSA-6238-1 | 2026-04-30 | trixie 6.12.85-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable code is reached through a local userspace page fault on an mmaped regular file, with the race driven by local truncate/ftruncate activity. I found no complete unauthenticated network path directly invoking this filemap fault-around path.
- AC:LAttack complexity, low
- The bug is a race, but an attacker can control both sides by faulting an mmaped file while concurrently shrinking it, and the reproducer-style stress path can be repeated. Large folios/THP are common enough for the affected path and not a rare attacker-independent condition.
- PR:LPrivileges required, low
- An unprivileged local user can create or open a writable regular file, mmap it, and truncate it; no capability or real root privilege is required. Normal file permissions are sufficient.
- UI:NUser interaction, none
- No separate victim action is required for the local attack path. The attacker triggers the mmap fault and truncate operations directly.
- S:UScope, unchanged
- The corruption occurs within the kernel memory-management/file-cache security authority. This is standard kernel memory corruption/possible privilege escalation, not a VM escape or cross-authority boundary by itself.
- C:HConfidentiality impact, high
- The overflow can cause PTEs to be installed for pages beyond the intended folio, potentially exposing unrelated physical memory to userspace. As kernel memory corruption, it is also reasonably capable of enabling broader information disclosure.
- I:HIntegrity impact, high
- The overlarge range corrupts page metadata such as mapcounts for pages outside the folio and creates incorrect mappings. This is out-of-bounds kernel memory corruption and is high-integrity impact under the required scoring guidance.
- A:HAvailability impact, high
- The fix commit documents reproducible Bad page state crashes and DEBUG_VM warnings from mapping past the folio. Kernel crash/oops availability impact is High.