{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-40006", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-40006" ], "published": "2025-10-20T15:27:24Z", "summary": "mm/hugetlb: fix folio is still mapped when deleted", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix folio is still mapped when deleted\n\nMigration may be raced with fallocating hole. remove_inode_single_folio\nwill unmap the folio if the folio is still mapped. However, it's called\nwithout folio lock. If the folio is migrated and the mapped pte has been\nconverted to migration entry, folio_mapped() returns false, and won't\nunmap it. Due to extra refcount held by remove_inode_single_folio,\nmigration fails, restores migration entry to normal pte, and the folio is\nmapped again. As a result, we triggered BUG in filemap_unaccount_folio.\n\nThe log is as follows:\n BUG: Bad page cache in process hugetlb pfn:156c00\n page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00\n head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0\n aops:hugetlbfs_aops ino:dcc dentry name(?):\"my_hugepage_file\"\n flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)\n page_type: f4(hugetlb)\n page dumped because: still mapped when deleted\n CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE\n Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015\n Call Trace:\n \n dump_stack_lvl+0x4f/0x70\n filemap_unaccount_folio+0xc4/0x1c0\n __filemap_remove_folio+0x38/0x1c0\n filemap_remove_folio+0x41/0xd0\n remove_inode_hugepages+0x142/0x250\n hugetlbfs_fallocate+0x471/0x5a0\n vfs_fallocate+0x149/0x380\n\nHold folio lock before checking if the folio is mapped to avold race with\nmigration.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.155", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-40006" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/bc1c9ce8aeff45318332035dbef9713fb9e982d7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/91f548e920fbf8be3f285bfa3fa045ae017e836d" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3e851448078f5b01f6264915df3cfef75e323a12" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c1dc0524ab2cc3982d4e0d2bfac71a0cd4d65c39" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c9c2a51f91aea70e89b496cac360cd795a2b3c26" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/910d7749346c4b0acdc6e4adfdc4a9984281a206" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/21ee79ce938127f88fe07e409c1817f477dbe7ea" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7b7387650dcf2881fd8bb55bcf3c8bd6c9542dd7" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - Exploitation requires local syscalls only \u2014 `memfd_create(MFD_HUGETLB)`/`mmap` plus `fallocate(FALLOC_FL_PUNCH_HOLE)` racing against `mbind`/`move_pages`. There is no network-reachable path into hugetlbfs fallocate.\nAC:L - The attacker controls both sides of the race with its own threads \u2014 one looping on punch-hole, the other looping on NUMA migration of the same mapping \u2014 and can retry indefinitely at no cost until the window is hit. Per race-condition guidance, attacker-driven races are Low.\nPR:L - `memfd_create(MFD_HUGETLB)` uses HUGETLB_ANONHUGE_INODE and bypasses the `can_do_hugetlb_shm()`/CAP_IPC_LOCK check entirely, and `MPOL_MF_MOVE` on one's own address space needs no capability, so an ordinary unprivileged local user can reach the whole path.\nUI:N - The attacking process performs every step itself; no victim action, mount, or file open by another user is needed.\nS:U - The vulnerable code and the corrupted resources are both in the host kernel's memory management, so the impact stays within a single security authority despite the severity.\nC:H - The huge page is unlinked from the page cache with its `mapping` cleared while the attacker retains writable PTEs, and hugetlb folios are explicitly excluded from `filemap_unaccount_folio()`'s recovery heuristic \u2014 leaving a stale mapping to a 2MB page the kernel may recycle to another process, container, or hugepage-backed KVM guest, yielding arbitrary read of that memory.\nI:H - The same stale writable mapping gives an arbitrary-write primitive over whatever the kernel later places in that recycled huge page, and the hugetlb reserve/subpool counters are decremented for a page still in use, corrupting pool accounting \u2014 memory corruption of this class is leveragable for control-flow hijack.\nA:H - The bug's directly observed symptom is the `BUG: Bad page cache ... still mapped when deleted` report, which is a hard `VM_BUG_ON_FOLIO()` panic under CONFIG_DEBUG_VM and a `TAINT_BAD_PAGE` plus unrecoverable page-cache/hugetlb-pool corruption otherwise, repeatable at will by an unprivileged user." } } }