{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2025-38447", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-04-16T04:51:24.018Z", "datePublished": "2025-07-25T15:27:29.360Z", "dateUpdated": "2026-08-05T12:01:58.222Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T12:01:58.222Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: fix potential out-of-bounds page table access during batched unmap\n\nAs pointed out by David[1], the batched unmap logic in\ntry_to_unmap_one() may read past the end of a PTE table when a large\nfolio's PTE mappings are not fully contained within a single page\ntable.\n\nWhile this scenario might be rare, an issue triggerable from userspace\nmust be fixed regardless of its likelihood. This patch fixes the\nout-of-bounds access by refactoring the logic into a new helper,\nfolio_unmap_pte_batch().\n\nThe new helper correctly calculates the safe batch size by capping the\nscan at both the VMA and PMD boundaries. To simplify the code, it also\nsupports partial batching (i.e., any number of pages from 1 up to the\ncalculated safe maximum), as there is no strong reason to special-case\nfor fully mapped folios." } ], "metrics": [ { "cvssV3_1": { "version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH" }, "scenarios": [ { "lang": "en", "value": "AV:L - The vulnerability is reached purely through local syscalls (mmap, madvise MADV_HUGEPAGE/MADV_FREE/MADV_PAGEOUT, mremap) against the attacker's own address space. There is no network- or adjacent-network-reachable path into the reclaim/rmap unmap code.\nAC:L - The attacker fully and deterministically controls every precondition — folio size, lazyfree state, PMD-straddling placement via an unaligned mremap, and the reclaim trigger via MADV_PAGEOUT — with no race to win and no attacker-independent condition. The required config (CONFIG_TRANSPARENT_HUGEPAGE) is ubiquitous and MADV_HUGEPAGE covers the thp=madvise default.\nPR:L - Only an ordinary unprivileged local user account is needed; every step uses unrestricted memory-management syscalls on private anonymous memory with no capability check anywhere along the path.\nUI:N - The attacking process performs the entire sequence itself and drives reclaim of its own folio via madvise(MADV_PAGEOUT); no victim action or interaction is involved.\nS:U - The out-of-bounds page-table access and the resulting corruption occur within the kernel's own security authority, the same authority the attacker is escalating within. No VM, IOMMU, or sandbox boundary is crossed by the primary defect.\nC:H - The bug reads up to ~4 KB of kernel memory past the end of a page-table page — far beyond a \"few bytes\" — and the resulting page-table corruption plus folio refcount underflow yields a use-after-free that can be leveraged into arbitrary kernel memory disclosure.\nI:H - When the OOB scan matches, get_and_clear_full_ptes()/set_ptes() write PTE-sized values past the end of the page-table page, and folio_ref_sub()/folio_remove_rmap_ptes() underflow the refcount and mapcount of a still-mapped folio, giving page-table-level memory corruption and a UAF write primitive suitable for privilege escalation.\nA:H - The out-of-bounds read can fault on an unmapped adjacent page (memory holes, DEBUG_PAGEALLOC/page poisoning, KASAN) causing an oops, and the refcount underflow frees a folio that is still mapped, reliably producing a kernel panic or corruption-induced crash." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "mm/rmap.c" ], "versions": [ { "version": "354dffd29575cdf13154e8fb787322354aa9efc4", "lessThan": "510fe9c15d07e765d96be9a9dc37e5057c6c09f4", "status": "affected", "versionType": "git" }, { "version": "354dffd29575cdf13154e8fb787322354aa9efc4", "lessThan": "ddd05742b45b083975a0855ef6ebbf88cf1f532a", "status": "affected", "versionType": "git" } ] }, { "product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "mm/rmap.c" ], "versions": [ { "version": "6.15", "status": "affected" }, { "version": "0", "lessThan": "6.15", "status": "unaffected", "versionType": "semver" }, { "version": "6.15.7", "lessThanOrEqual": "6.15.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.16", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix" } ] } ], "cpeApplicability": [ { "nodes": [ { "operator": "OR", "negate": false, "cpeMatch": [ { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.15", "versionEndExcluding": "6.15.7" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.15", "versionEndExcluding": "6.16" } ] } ] } ], "references": [ { "url": "https://git.kernel.org/stable/c/510fe9c15d07e765d96be9a9dc37e5057c6c09f4" }, { "url": "https://git.kernel.org/stable/c/ddd05742b45b083975a0855ef6ebbf88cf1f532a" } ], "title": "mm/rmap: fix potential out-of-bounds page table access during batched unmap", "x_generator": { "engine": "bippy-1.2.0" } } } }