CVE-2025-40006: mm/hugetlb: fix folio is still mapped when deleted
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix folio is still mapped when deleted
Migration may be raced with fallocating hole. remove_inode_single_folio
will unmap the folio if the folio is still mapped. However, it's called
without folio lock. If the folio is migrated and the mapped pte has been
converted to migration entry, folio_mapped() returns false, and won't
unmap it. Due to extra refcount held by remove_inode_single_folio,
migration fails, restores migration entry to normal pte, and the folio is
mapped again. As a result, we triggered BUG in filemap_unaccount_folio.
The log is as follows:
BUG: Bad page cache in process hugetlb pfn:156c00
page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00
head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0
aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file"
flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)
page_type: f4(hugetlb)
page dumped because: still mapped when deleted
CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
Call Trace:
<TASK>
dump_stack_lvl+0x4f/0x70
filemap_unaccount_folio+0xc4/0x1c0
__filemap_remove_folio+0x38/0x1c0
filemap_remove_folio+0x41/0xd0
remove_inode_hugepages+0x142/0x250
hugetlbfs_fallocate+0x471/0x5a0
vfs_fallocate+0x149/0x380
Hold folio lock before checking if the folio is mapped to avold race with
migration.
Security readout for executives and security teams
Plain-English summary
A local low-privilege user may trigger a Linux kernel race involving huge-page files. The observed result is a kernel BUG and bad page-cache state, creating serious availability risk; the supplied CVSS also rates confidentiality and integrity impacts high. The issue is not described as remotely exploitable.
Executive priority
Prioritize remediation on shared compute, virtualization, database, and high-performance systems using huge pages. Accelerate patching where untrusted or tenant-controlled local workloads run. Other systems should enter the normal high-severity kernel update cycle after confirming exposure with the operating-system vendor.
Technical view
During concurrent hugetlbfs hole punching and folio migration, a mapped-state check occurs without the folio lock. A temporary migration entry can make the folio appear unmapped. Migration then fails, restores the mapping, and deletion encounters a still-mapped folio, triggering the reported page-cache BUG. The fix locks the folio before checking its mapped state.
Likely exposure
Exposure is most likely on Linux systems using hugetlbfs or application-managed huge pages and allowing low-privileged local code execution. The supplied vector is local with low privileges and no user interaction. The bundle's version metadata is broad and insufficiently clear for determining exact distribution package ranges.
Exploitation context
The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation or a public exploit. The CVSS vector reports low attack complexity, but the underlying condition involves a concurrency race. Treat exploitation status as unconfirmed rather than assuming the issue is being weaponized.
Researcher notes
The reported invariant failure occurs because folio_mapped() can return false while page-table entries are temporarily represented as migration entries. An extra reference prevents migration completion, after which the normal mapping is restored. Locking serializes the mapped-state check against migration. No CWE was supplied, and the precise confidentiality or integrity mechanism is not documented.
Mitigation direction
Identify Linux systems using hugetlbfs or application-managed huge pages.
Apply a vendor-supported kernel update incorporating the cited stable fix.
Prioritize shared or multi-user hosts where low-privileged local code can run.
If patching is delayed, consult vendor guidance for supported exposure-reduction measures.
Validation and detection
Record running kernel versions and compare them with current distribution security advisories.
Confirm the installed kernel changelog includes the CVE or corresponding stable commit.
Verify patched systems booted into the updated kernel.
Monitor for "Bad page cache" or "still mapped when deleted" kernel diagnostics.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-40006 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
9Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.