Skip to main content
VulnerabilityPublished Updated

CVE-2025-40006: Linux kernel · mm/hugetlb: fix folio is still mapped when deleted

Affects Linux kernelSource GCVE Database

0

Not known to be exploited · CVSS 7.8 High · fixed in 5.15.0-1110.119~20.04.1 : patch Linux kernel soon.

Data as of 26 Oct 2026, 13:47 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 9% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 5.15.0-1110.119~20.04.1, 5.15.0-1100.109~20.04.1, 5.15.0-1100.107~20.04.2 +2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 20 Oct 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
linux-azureAffected
  • <5.15.0-1100.107~20.04.2
  • <5.15.0-1110.119~20.04.1
  • <5.15.0-1100.109~20.04.1
  • <5.15.0-170.180~20.04.3
  • <5.15.0-1094.97~20.04.1
Fixed in
  • 5.15.0-1100.107~20.04.2
  • 5.15.0-1110.119~20.04.1
  • 5.15.0-1100.109~20.04.1
  • 5.15.0-170.180~20.04.3
  • 5.15.0-1094.97~20.04.1

AI-suggested

A fix has been implemented in the Linux kernel to hold the folio lock before checking if the folio is mapped, preventing the race condition. Users should apply the official kernel update that includes this patch. Patch status is not explicitly confirmed in the provided data; check the Linux kernel vendor advisory for the exact fixed versions and update accordingly.

Description

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.

References

Community reviews

Loading reviews…