| { |
| "containers": { |
| "cna": { |
| "providerMetadata": { |
| "orgId": "f4215fc3-5b6b-47ff-a258-f7189bd81038" |
| }, |
| "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---" |
| } |
| ], |
| "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" |
| } |
| } |
| }, |
| "cveMetadata": { |
| "assignerOrgId": "f4215fc3-5b6b-47ff-a258-f7189bd81038", |
| "cveID": "CVE-2023-52934", |
| "requesterUserId": "gregkh@kernel.org", |
| "serial": "1", |
| "state": "PUBLISHED" |
| }, |
| "dataType": "CVE_RECORD", |
| "dataVersion": "5.0" |
| } |
