{"id":"DEBIAN-CVE-2023-52934","details":"In the Linux kernel, the following vulnerability has been resolved:  mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups  In commit 34488399fa08 (\"mm/madvise: add file and shmem support to MADV_COLLAPSE\") we make the following change to find_pmd_or_thp_or_none():  \t-       if (!pmd_present(pmde)) \t-               return SCAN_PMD_NULL; \t+       if (pmd_none(pmde)) \t+               return SCAN_PMD_NONE;  This was for-use by MADV_COLLAPSE file/shmem codepaths, where MADV_COLLAPSE might identify a pte-mapped hugepage, only to have khugepaged race-in, free the pte table, and clear the pmd.  Such codepaths include:  A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER    already in the pagecache. B) In retract_page_tables(), if we fail to grab mmap_lock for the target    mm/address.  In these cases, collapse_pte_mapped_thp() really does expect a none (not just !present) pmd, and we want to suitably identify that case separate from the case where no pmd is found, or it's a bad-pmd (of course, many things could happen once we drop mmap_lock, and the pmd could plausibly undergo multiple transitions due to intervening fault, split, etc).  Regardless, the code is prepared install a huge-pmd only when the existing pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.  However, the commit introduces a logical hole; namely, that we've allowed !none- && !huge- && !bad-pmds to be classified as genuine pte-table-mapping-pmds.  One such example that could leak through are swap entries.  The pmd values aren't checked again before use in pte_offset_map_lock(), which is expecting nothing less than a genuine pte-table-mapping-pmd.  We want to put back the !pmd_present() check (below the pmd_none() check), but need to be careful to deal with subtleties in pmd transitions and treatments by various arch.  The issue is that __split_huge_pmd_locked() temporarily clears the present bit (or otherwise marks the entry as invalid), but pmd_present() and pmd_trans_huge() still need to return true while the pmd is in this transitory state.  For example, x86's pmd_present() also checks the _PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also checks a PMD_PRESENT_INVALID bit.  Covering all 4 cases for x86 (all checks done on the same pmd value):  1) pmd_present() && pmd_trans_huge()    All we actually know here is that the PSE bit is set. Either:    a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE       is set.       =\u003e huge-pmd    b) We are currently racing with __split_huge_page().  The danger here       is that we proceed as-if we have a huge-pmd, but really we are       looking at a pte-mapping-pmd.  So, what is the risk of this       danger?        The only relevant path is:  \tmadvise_collapse() -\u003e collapse_pte_mapped_thp()        Where we might just incorrectly report back \"success\", when really       the memory isn't pmd-backed.  This is fine, since split could       happen immediately after (actually) successful madvise_collapse().       So, it should be safe to just assume huge-pmd here.  2) pmd_present() && !pmd_trans_huge()    Either:    a) PSE not set and either PRESENT or PROTNONE is.       =\u003e pte-table-mapping pmd (or PROT_NONE)    b) devmap.  This routine can be called immediately after       unlocking/locking mmap_lock -- or called with no locks held (see       khugepaged_scan_mm_slot()), so previous VMA checks have since been       invalidated.  3) !pmd_present() && pmd_trans_huge()   Not possible.  4) !pmd_present() && !pmd_trans_huge()   Neither PRESENT nor PROTNONE set   =\u003e not present  I've checked all archs that implement pmd_trans_huge() (arm64, riscv, powerpc, longarch, x86, mips, s390) and this logic roughly translates (though devmap treatment is unique to x86 and powerpc, and (3) doesn't necessarily hold in general -- but that doesn't matter since !pmd_present() always takes failure path).  Also, add a comment above find_pmd_or_thp_or_none() ---truncated---","modified":"2026-09-15T09:02:49.239192637Z","published":"2025-03-27T17:15:43.207Z","upstream":["CVE-2023-52934"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2023-52934"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.11-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2023-52934.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.11-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2023-52934.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.11-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2023-52934.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}