{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2023-52934", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-08-21T06:07:11.020Z", "datePublished": "2025-03-27T16:37:14.857Z", "dateUpdated": "2026-08-05T09:12:08.975Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T09:12:08.975Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups\n\nIn commit 34488399fa08 (\"mm/madvise: add file and shmem support to\nMADV_COLLAPSE\") we make the following change to find_pmd_or_thp_or_none():\n\n\t- if (!pmd_present(pmde))\n\t- return SCAN_PMD_NULL;\n\t+ if (pmd_none(pmde))\n\t+ return SCAN_PMD_NONE;\n\nThis was for-use by MADV_COLLAPSE file/shmem codepaths, where\nMADV_COLLAPSE might identify a pte-mapped hugepage, only to have\nkhugepaged race-in, free the pte table, and clear the pmd. Such codepaths\ninclude:\n\nA) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER\n already in the pagecache.\nB) In retract_page_tables(), if we fail to grab mmap_lock for the target\n mm/address.\n\nIn these cases, collapse_pte_mapped_thp() really does expect a none (not\njust !present) pmd, and we want to suitably identify that case separate\nfrom the case where no pmd is found, or it's a bad-pmd (of course, many\nthings could happen once we drop mmap_lock, and the pmd could plausibly\nundergo multiple transitions due to intervening fault, split, etc). \nRegardless, the code is prepared install a huge-pmd only when the existing\npmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.\n\nHowever, the commit introduces a logical hole; namely, that we've allowed\n!none- && !huge- && !bad-pmds to be classified as genuine\npte-table-mapping-pmds. One such example that could leak through are swap\nentries. The pmd values aren't checked again before use in\npte_offset_map_lock(), which is expecting nothing less than a genuine\npte-table-mapping-pmd.\n\nWe want to put back the !pmd_present() check (below the pmd_none() check),\nbut need to be careful to deal with subtleties in pmd transitions and\ntreatments by various arch.\n\nThe issue is that __split_huge_pmd_locked() temporarily clears the present\nbit (or otherwise marks the entry as invalid), but pmd_present() and\npmd_trans_huge() still need to return true while the pmd is in this\ntransitory state. For example, x86's pmd_present() also checks the\n_PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also\nchecks a PMD_PRESENT_INVALID bit.\n\nCovering all 4 cases for x86 (all checks done on the same pmd value):\n\n1) pmd_present() && pmd_trans_huge()\n All we actually know here is that the PSE bit is set. Either:\n a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE\n is set.\n => huge-pmd\n b) We are currently racing with __split_huge_page(). The danger here\n is that we proceed as-if we have a huge-pmd, but really we are\n looking at a pte-mapping-pmd. So, what is the risk of this\n danger?\n\n The only relevant path is:\n\n\tmadvise_collapse() -> collapse_pte_mapped_thp()\n\n Where we might just incorrectly report back \"success\", when really\n the memory isn't pmd-backed. This is fine, since split could\n happen immediately after (actually) successful madvise_collapse().\n So, it should be safe to just assume huge-pmd here.\n\n2) pmd_present() && !pmd_trans_huge()\n Either:\n a) PSE not set and either PRESENT or PROTNONE is.\n => pte-table-mapping pmd (or PROT_NONE)\n b) devmap. This routine can be called immediately after\n unlocking/locking mmap_lock -- or called with no locks held (see\n khugepaged_scan_mm_slot()), so previous VMA checks have since been\n invalidated.\n\n3) !pmd_present() && pmd_trans_huge()\n Not possible.\n\n4) !pmd_present() && !pmd_trans_huge()\n Neither PRESENT nor PROTNONE set\n => not present\n\nI've checked all archs that implement pmd_trans_huge() (arm64, riscv,\npowerpc, longarch, x86, mips, s390) and this logic roughly translates\n(though devmap treatment is unique to x86 and powerpc, and (3) doesn't\nnecessarily hold in general -- but that doesn't matter since\n!pmd_present() always takes failure path).\n\nAlso, add a comment above find_pmd_or_thp_or_none()\n---truncated---" } ], "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 - Reached via the local madvise(MADV_COLLAPSE) syscall on the caller's own address space (mm/madvise.c → madvise_collapse → find_pmd_or_thp_or_none / collapse_pte_mapped_thp); not network- or physically reachable.\nAC:L - An unprivileged attacker can drive both sides of the race—issuing MADV_COLLAPSE (which drops mmap_lock) while concurrently triggering THP migration of the same range via move_pages on its own mm—and can retry indefinitely; similar MADV_COLLAPSE page-table races were scored AC:L.\nPR:L - madvise(MADV_COLLAPSE) requires only an ordinary local user account with no capability checks; move_pages on the caller's own pid likewise needs no privileges.\nUI:N - The attacker fully controls the triggering syscalls and memory layout in its own process; no victim action is required.\nS:U - Impact is confined to the host kernel's page-table handling (standard local privilege-escalation/corruption scope) and does not cross a VM, IOMMU, or other security-authority boundary.\nC:H - Misclassified swap/migration PMDs are passed to pte_offset_map_lock(), which interprets non-page-table memory as PTEs; that type confusion can disclose kernel or cross-process memory when bogus PTE contents are walked, consistent with other page-table confusion scores.\nI:H - The collapse paths then operate on those forged PTEs (including page_remove_rmap and collapse_and_free_pmd), corrupting page/rmap state and yielding an arbitrary write/control-flow primitive from attacker-influenced page contents treated as a page table.\nA:H - Dereferencing a swap/migration entry as a PTE table reliably causes kernel oops/panic or further corruption that can hang or crash the system, and can be repeated by an unprivileged user." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "mm/khugepaged.c" ], "versions": [ { "version": "34488399fa08faaf664743fa54b271eb6f9e1321", "lessThan": "96aaaf8666010a39430cecf8a65c7ce2908a030f", "status": "affected", "versionType": "git" }, { "version": "34488399fa08faaf664743fa54b271eb6f9e1321", "lessThan": "edb5d0cf5525357652aff6eacd9850b8ced07143", "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/khugepaged.c" ], "versions": [ { "version": "6.1", "status": "affected" }, { "version": "0", "lessThan": "6.1", "status": "unaffected", "versionType": "semver" }, { "version": "6.1.11", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.2", "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.1", "versionEndExcluding": "6.1.11" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.1", "versionEndExcluding": "6.2" } ] } ] } ], "references": [ { "url": "https://git.kernel.org/stable/c/96aaaf8666010a39430cecf8a65c7ce2908a030f" }, { "url": "https://git.kernel.org/stable/c/edb5d0cf5525357652aff6eacd9850b8ced07143" } ], "title": "mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups", "x_generator": { "engine": "bippy-1.2.0" } } } }