Skip to main content

Linux Kernel CVE-2025-40006

HIGH
2025-10-20 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Information Disclosure Linux Ubuntu Red Hat Suse
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Local hugetlbfs access needed (AV:L/PR:L); winning the migration-vs-deletion race is timing-dependent (AC:H); demonstrated crash plus potential use-after-free justify high C/I/A.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
4.7 MEDIUM
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
4.7 MEDIUM
qualitative

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 08:01 vuln.today
CVE Published
Oct 20, 2025 - 16:15 cve.org
HIGH 7.8

DescriptionCVE.org

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.

AnalysisAI

Local denial of service (and potential memory corruption) in the Linux kernel's hugetlbfs subsystem occurs because remove_inode_single_folio checks folio mapping state without holding the folio lock, racing with page migration; when a hugepage is migrated to a migration entry, folio_mapped() wrongly returns false, migration is then reverted, and the folio ends up mapped after deletion, tripping a BUG in filemap_unaccount_folio. Affected are kernels using hugetlbfs with hole-punch fallocate concurrent with migration (observed on 6.17-rc5 and backported to multiple stable branches). No public exploit identified at time of analysis; EPSS is low (0.24%, 15th percentile) and the issue is not in CISA KEV.

Technical ContextAI

The flaw lives in mm/hugetlb (hugetlbfs page-cache management). When hugetlbfs_fallocate() punches a hole, remove_inode_hugepages() calls remove_inode_single_folio() to remove and, if necessary, unmap each folio. The bug is a locking/ordering error: the mapped-state check (folio_mapped()) runs before the folio lock is acquired, so it races with folio migration. During migration a present PTE is temporarily converted to a swap-like migration entry, making folio_mapped() report the folio as unmapped; the extra refcount held by the removal path then causes migration to fail and restore the normal PTE, leaving the folio mapped after it has been removed from the page cache. This is a classic time-of-check/time-of-use race (CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization) even though the input lists CWE as N/A. The fix moves folio lock acquisition ahead of the folio_mapped() check to serialize against migration.

Affected ProductsAI

The Linux kernel hugetlbfs/mm-hugetlb subsystem is affected; the crash was reproduced on 6.17.0-rc5 (commit 7aac71907bde) and the fix was propagated across multiple stable branches, as evidenced by the eight git.kernel.org/stable commits in the references (e.g., 21ee79ce9381, 3e851448078f, 7b7387650dcf, 910d7749346c, 91f548e920fb, bc1c9ce8aeff, c1dc0524ab2c, c9c2a51f91ae). No CPE strings were provided in the input, so exact version ranges per stable series are not enumerable from this data; the tags indicate Linux/Ubuntu distributions are in scope. Consult the per-branch commits above and your distribution's kernel advisory for the precise fixed version in each series.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - apply the kernel update for your stable series that contains the fix (the commits at git.kernel.org/stable, e.g. https://git.kernel.org/stable/c/21ee79ce938127f88fe07e409c1817f477dbe7ea and the seven sibling commits, which move folio-lock acquisition before the folio_mapped() check). For distribution kernels, install the vendor-provided patched kernel (Ubuntu is explicitly tagged) once published and reboot. If patching must be deferred on a multi-tenant host, reduce exposure by restricting untrusted users' ability to create hugetlbfs mappings - for example unmount or do not expose a hugetlbfs mount, and gate MAP_HUGETLB usage via /proc/sys/vm/nr_hugepages set to 0 or via the hugetlb cgroup / group ownership of the mount so only trusted service accounts can allocate hugepages; the trade-off is that legitimate hugepage-dependent workloads (databases, DPDK, large-page VMs) will lose functionality. Reducing conditions that trigger migration (e.g., disabling automatic NUMA balancing via kernel.numa_balancing=0) narrows the race window but does not close it and can degrade NUMA performance.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Container suse/sl-micro/6.0/baremetal-os-container:latest Container suse/sl-micro/6.1/baremetal-os-container:latest Affected
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.95 Container suse/sl-micro/6.1/base-os-container:2.2.1-5.80 Affected
Container suse/sl-micro/6.0/kvm-os-container:2.1.3-6.115 Container suse/sl-micro/6.1/kvm-os-container:2.2.1-5.83 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.146 Container suse/sl-micro/6.1/rt-os-container:2.2.1-5.91 Affected
Image SL-Micro-Azure Image SL-Micro-BYOS-Azure Image SL-Micro-BYOS-EC2 Image SL-Micro-BYOS-GCE Image SL-Micro-EC2 Image SLE-Micro Image SLE-Micro-Azure Image SLE-Micro-BYOS Image SLE-Micro-BYOS-Azure Image SLE-Micro-BYOS-EC2 Image SLE-Micro-BYOS-GCE Image SLE-Micro-EC2 Image SLE-Micro-GCE Image SUSE-Multi-Linux-Manager-Proxy-BYOS-Azure Image SUSE-Multi-Linux-Manager-Proxy-BYOS-EC2 Image SUSE-Multi-Linux-Manager-Proxy-BYOS-GCE Image SUSE-Multi-Linux-Manager-Server-Azure-llc Image SUSE-Multi-Linux-Manager-Server-Azure-ltd Image SUSE-Multi-Linux-Manager-Server-BYOS-Azure Image SUSE-Multi-Linux-Manager-Server-BYOS-EC2 Image SUSE-Multi-Linux-Manager-Server-BYOS-GCE Image SUSE-Multi-Linux-Manager-Server-EC2-llc Image SUSE-Multi-Linux-Manager-Server-EC2-ltd Affected

Share

CVE-2025-40006 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy