{
  "threat_severity" : "Moderate",
  "public_date" : "2025-03-27T00:00:00Z",
  "bugzilla" : {
    "description" : "kernel: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups",
    "id" : "2355463",
    "url" : "https://bugzilla.redhat.com/show_bug.cgi?id=2355463"
  },
  "cvss3" : {
    "cvss3_base_score" : "4.7",
    "cvss3_scoring_vector" : "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
    "status" : "verified"
  },
  "cwe" : "CWE-362",
  "details" : [ "In the Linux kernel, the following vulnerability has been resolved:\nmm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups\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-       if (!pmd_present(pmde))\n-               return SCAN_PMD_NULL;\n+       if (pmd_none(pmde))\n+               return SCAN_PMD_NONE;\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:\nA) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER\nalready in the pagecache.\nB) In retract_page_tables(), if we fail to grab mmap_lock for the target\nmm/address.\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.\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.\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.\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.\nCovering all 4 cases for x86 (all checks done on the same pmd value):\n1) pmd_present() && pmd_trans_huge()\nAll we actually know here is that the PSE bit is set. Either:\na) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE\nis set.\n=> huge-pmd\nb) We are currently racing with __split_huge_page().  The danger here\nis that we proceed as-if we have a huge-pmd, but really we are\nlooking at a pte-mapping-pmd.  So, what is the risk of this\ndanger?\nThe only relevant path is:\nmadvise_collapse() -> collapse_pte_mapped_thp()\nWhere we might just incorrectly report back \"success\", when really\nthe memory isn't pmd-backed.  This is fine, since split could\nhappen immediately after (actually) successful madvise_collapse().\nSo, it should be safe to just assume huge-pmd here.\n2) pmd_present() && !pmd_trans_huge()\nEither:\na) PSE not set and either PRESENT or PROTNONE is.\n=> pte-table-mapping pmd (or PROT_NONE)\nb) devmap.  This routine can be called immediately after\nunlocking/locking mmap_lock -- or called with no locks held (see\nkhugepaged_scan_mm_slot()), so previous VMA checks have since been\ninvalidated.\n3) !pmd_present() && pmd_trans_huge()\nNot possible.\n4) !pmd_present() && !pmd_trans_huge()\nNeither PRESENT nor PROTNONE set\n=> not present\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).\nAlso, add a comment above find_pmd_or_thp_or_none()\n---truncated---" ],
  "affected_release" : [ {
    "product_name" : "Red Hat Enterprise Linux 9",
    "release_date" : "2024-04-30T00:00:00Z",
    "advisory" : "RHSA-2024:2394",
    "cpe" : "cpe:/a:redhat:enterprise_linux:9",
    "package" : "kernel-0:5.14.0-427.13.1.el9_4"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "release_date" : "2024-04-30T00:00:00Z",
    "advisory" : "RHSA-2024:2394",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9",
    "package" : "kernel-0:5.14.0-427.13.1.el9_4"
  } ],
  "package_state" : [ {
    "product_name" : "Red Hat Enterprise Linux 10",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:10"
  }, {
    "product_name" : "Red Hat Enterprise Linux 6",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:6"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Not affected",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Not affected",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Not affected",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Fix deferred",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  } ],
  "references" : [ "https://www.cve.org/CVERecord?id=CVE-2023-52934\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-52934\nhttps://lore.kernel.org/linux-cve-announce/2025032720-CVE-2023-52934-bd3c@gregkh/T" ],
  "name" : "CVE-2023-52934",
  "csaw" : false
}