CVE-2023-52934
published 2025-03-27CVE-2023-52934: In the Linux kernel, the following vulnerability has been resolved: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups In commit 34488399fa08 ("mm/madvise…
PriorityP416medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.11%
1.8th percentile
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():
- if (!pmd_present(pmde))
- return SCAN_PMD_NULL;
+ if (pmd_none(pmde))
+ 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
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.11-1 (bookworm) | linux 6.1.11-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 34488399fa08faaf664743fa54b271eb6f9e1321 < 96aaaf8666010a39430cecf8a65c7ce2908a030f | 96aaaf8666010a39430cecf8a65c7ce2908a030f |
| linux | linux | >= 34488399fa08faaf664743fa54b271eb6f9e1321 < edb5d0cf5525357652aff6eacd9850b8ced07143 | edb5d0cf5525357652aff6eacd9850b8ced07143 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.11-1 | 6.1.11-1 |
| linux | linux_kernel | >= 0 < 6.1.11-1 | 6.1.11-1 |
| linux | linux_kernel | >= 0 < 6.1.11-1 | 6.1.11-1 |
| linux | linux_kernel | >= 6.1 < 6.1.11 | 6.1.11 |
CVSS provenance
nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv4.7MEDIUM
vendor_debian4.7MEDIUM
vendor_redhat4.7MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups
vendor_redhat·2025-03-27·CVSS 4.7
CVE-2023-52934 [MEDIUM] CWE-362 kernel: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups
kernel: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups
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():
- if (!pmd_present(pmde))
- return SCAN_PMD_NULL;
+ if (pmd_none(pmde))
+ 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 targe
Debian
CVE-2023-52934: linux - In the Linux kernel, the following vulnerability has been resolved: mm/MADV_COL...
vendor_debian·2023·CVSS 4.7
CVE-2023-52934 [MEDIUM] CVE-2023-52934: linux - In the Linux kernel, the following vulnerability has been resolved: mm/MADV_COL...
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(): - if (!pmd_present(pmde)) - return SCAN_PMD_NULL; + if (pmd_none(pmde)) + 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
OSV
CVE-2023-52934: In the Linux kernel, the following vulnerability has been resolved: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups In commit 34488399fa08 ("mm/m
osv·2025-03-27·CVSS 4.7
CVE-2023-52934 [MEDIUM] CVE-2023-52934: In the Linux kernel, the following vulnerability has been resolved: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups In commit 34488399fa08 ("mm/m
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(): - if (!pmd_present(pmde)) - return SCAN_PMD_NULL; + if (pmd_none(pmde)) + 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
GHSA
GHSA-6rc5-mh5g-63wm: In the Linux kernel, the following vulnerability has been resolved:
mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups
In commit 34488399fa08 ("mm
ghsa_unreviewed·2025-03-27
CVE-2023-52934 [MEDIUM] CWE-362 GHSA-6rc5-mh5g-63wm: In the Linux kernel, the following vulnerability has been resolved:
mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups
In commit 34488399fa08 ("mm
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():
- if (!pmd_present(pmde))
- return SCAN_PMD_NULL;
+ if (pmd_none(pmde))
+ 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()
No detection rules found.
No public exploits indexed.
2025-03-27
Published