Linux Kernel bis 6.1.10 find_pmd_or_thp_or_none erweiterte Rechte

| CVSS Meta Temp Score | Aktueller Exploitpreis (≈) | CTI Interest Score |
|---|---|---|
| 4.5 | $0-$5k | 0.00 |
Zusammenfassung
In Linux Kernel bis 6.1.10 wurde eine problematische Schwachstelle ausgemacht. Betroffen davon ist die Funktion find_pmd_or_thp_or_none. Dank Manipulation mit unbekannten Daten kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden.
Die Verwundbarkeit wird mit der eindeutigen Identifikation CVE-2023-52934 gehandelt. Es ist soweit kein Exploit verfügbar.
Als bestmögliche Massnahme wird das Einspielen eines Upgrades empfohlen.
Details
In Linux Kernel bis 6.1.10 wurde eine Schwachstelle ausgemacht. Sie wurde als problematisch eingestuft. Hierbei betrifft es die Funktion find_pmd_or_thp_or_none. Mittels Manipulieren mit einer unbekannten Eingabe kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-371. Die genauen Auswirkungen eines erfolgreichen Angriffs sind bisher nicht bekannt. CVE fasst zusammen:
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 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.
=> 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:
madvise_collapse() -> 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.
=> 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
=> 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---Auf git.kernel.org kann das Advisory eingesehen werden. Eine eindeutige Identifikation der Schwachstelle wird seit dem 21.08.2024 mit CVE-2023-52934 vorgenommen. Das Ausnutzen gilt als schwierig. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht. Als Preis für einen Exploit ist zur Zeit ungefähr mit USD $0-$5k zu rechnen (Preisberechnung vom 07.12.2025).
Ein Upgrade auf die Version 6.1.11 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 96aaaf8666010a39430cecf8a65c7ce2908a030f/edb5d0cf5525357652aff6eacd9850b8ced07143 beheben. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.
Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von CERT Bund (WID-SEC-2025-0649) dokumentiert. If you want to get best quality of vulnerability data, you may have to visit VulDB.
Betroffen
- Google Container-Optimized OS
- Debian Linux
- Amazon Linux 2
- Red Hat Enterprise Linux
- Ubuntu Linux
- SUSE Linux
- Oracle Linux
- SUSE openSUSE
- Dell Avamar
- Open Source Linux Kernel
- SolarWinds Security Event Manager
- Dell NetWorker
- Dell Secure Connect Gateway
Produkt
Typ
Hersteller
Name
Version
Lizenz
Webseite
- Hersteller: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Zuverlässigkeit: 🔍
CVSSv3
VulDB Meta Base Score: 4.6VulDB Meta Temp Score: 4.6
VulDB Base Score: 4.6
VulDB Temp Score: 4.4
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍
NVD Base Score: 4.7
NVD Vector: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vektor | Komplexität | Authentisierung | Vertraulichkeit | Integrität | Verfügbarkeit |
|---|---|---|---|---|---|
| freischalten | freischalten | freischalten | freischalten | freischalten | freischalten |
| freischalten | freischalten | freischalten | freischalten | freischalten | freischalten |
| freischalten | freischalten | freischalten | freischalten | freischalten | freischalten |
VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Zuverlässigkeit: 🔍
Exploiting
Klasse: Erweiterte RechteCWE: CWE-371
CAPEC: 🔍
ATT&CK: 🔍
Physisch: Teilweise
Lokal: Ja
Remote: Teilweise
Verfügbarkeit: 🔍
Status: Nicht definiert
EPSS Score: 🔍
EPSS Percentile: 🔍
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍
| 0-Day | freischalten | freischalten | freischalten | freischalten |
|---|---|---|---|---|
| Heute | freischalten | freischalten | freischalten | freischalten |
Threat Intelligence
Interesse: 🔍Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍
Gegenmassnahmen
Empfehlung: UpgradeStatus: 🔍
0-Day Time: 🔍
Upgrade: Kernel 6.1.11
Patch: 96aaaf8666010a39430cecf8a65c7ce2908a030f/edb5d0cf5525357652aff6eacd9850b8ced07143
Timeline
21.08.2024 🔍27.03.2025 🔍
27.03.2025 🔍
07.12.2025 🔍
Quellen
Hersteller: kernel.orgAdvisory: git.kernel.org
Status: Bestätigt
CVE: CVE-2023-52934 (🔍)
GCVE (CVE): GCVE-0-2023-52934
GCVE (VulDB): GCVE-100-301714
CERT Bund: WID-SEC-2025-0649 - Linux Kernel: Mehrere Schwachstellen
Eintrag
Erstellt: 27.03.2025 17:59Aktualisierung: 07.12.2025 01:44
Anpassungen: 27.03.2025 17:59 (57), 24.08.2025 08:06 (7), 28.10.2025 21:06 (11), 07.12.2025 01:44 (1)
Komplett: 🔍
Cache ID: 216::103
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Bisher keine Kommentare. Sprachen: de + en.
Bitte loggen Sie sich ein, um kommentieren zu können.