Linux Kernel bis 7.2.10 Mount Namespace create_new_namespace erweiterte Rechte

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
3.2$0-$5k0.79

Zusammenfassunginfo

Es wurde eine Schwachstelle in Linux Kernel bis 7.2.10 gefunden. Sie wurde als problematisch eingestuft. Hierbei geht es um die Funktion create_new_namespace der Komponente Mount Namespace. Die Veränderung resultiert in erweiterte Rechte. Die Identifikation der Schwachstelle findet als CVE-2026-98988 statt. Der Angriff ist nur lokal möglich. Es steht kein Exploit zur Verfügung. Es wird geraten, die betroffene Komponente zu aktualisieren.

Detailsinfo

In Linux Kernel bis 7.2.10 wurde eine Schwachstelle gefunden. Sie wurde als problematisch eingestuft. Das betrifft die Funktion create_new_namespace der Komponente Mount Namespace. Dank der Manipulation mit einer unbekannten Eingabe kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-269. Auswirkungen hat dies auf die Vertraulichkeit. Die Zusammenfassung von CVE lautet:

In the Linux kernel, the following vulnerability has been resolved: namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE open_tree(OPEN_TREE_NAMESPACE) creates a new mount namespace from a copy of the tree at the given path. The caller needs to be privileged over its current user namespace because the new mount namespace will be owned by it. It doesn't need to be privileged over the mount namespace the tree is copied from. An unprivileged user just needs to create a user namespace first. The copy follows the rules of a detached bind mount. Without AT_RECURSIVE only the mount itself is cloned and its children are left out. With AT_RECURSIVE unbindable mounts are skipped. Both is fine when the caller has privileges over the source mount namespace because it could unmount those mounts anyway. Not so for an unprivileged user in that mount namespace. For them a mount namespace copy is what unshare() does. copy_mnt_ns() copies everything including unbindable mounts and lock_mnt_tree() makes sure nothing can be unmounted in the copy. Nothing that was covered gets revealed. create_new_namespace() only does the locking and so the covered content is right there in the new mount namespace: # mount -t tmpfs none /tmp/otn; mkdir /tmp/otn/covered # echo hidden > /tmp/otn/covered/under.txt # mount -t tmpfs none /tmp/otn/covered uid 1000, after unshare(CLONE_NEWUSER): fd = open_tree(AT_FDCWD, "/tmp/otn", OPEN_TREE_NAMESPACE); setns(fd, CLONE_NEWNS); open("/covered/under.txt", O_RDONLY) -> "hidden" Covering paths with mounts is how container runtimes mask parts of /proc and /sys and how admins hide things. When the caller's user namespace doesn't own the source mount namespace copy the way unshare() does and refuse a non-recursive copy of a mount that has anything mounted below the requested directory and copy unbindable mounts in a recursive copy. A caller that is privileged over the source mount namespace sees no change.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Verwundbarkeit wird seit dem 25.09.2026 als CVE-2026-98988 geführt. Das Ausnutzen gilt als leicht. Der Angriff muss lokal angegangen werden. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht. Ein Exploit zur Schwachstelle wird momentan etwa USD $0-$5k kosten (Preisberechnung vom 23.10.2026). Als Angriffstechnik weist das MITRE ATT&CK Projekt die ID T1068 aus.

Ein Aktualisieren auf die Version 7.2.11 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches b8a94a405ddcf45e9470789e0a821d8f2aa4ca10/0febe278ec45b1ccdbe9bd5ff1ba365d8fd55e2a lösen. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 3.3
VulDB Meta Temp Score: 3.2

VulDB Base Score: 3.3
VulDB Temp Score: 3.2
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Erweiterte Rechte
CWE: CWE-269 / CWE-266
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Nein

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 7.2.11
Patch: b8a94a405ddcf45e9470789e0a821d8f2aa4ca10/0febe278ec45b1ccdbe9bd5ff1ba365d8fd55e2a

Timelineinfo

25.09.2026 CVE zugewiesen
23.10.2026 +28 Tage Advisory veröffentlicht
23.10.2026 +0 Tage VulDB Eintrag erstellt
23.10.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-98988 (🔒)
GCVE (CVE): GCVE-0-2026-98988
GCVE (VulDB): GCVE-100-425821

Eintraginfo

Erstellt: 23.10.2026 15:34
Anpassungen: 23.10.2026 15:34 (59)
Komplett: 🔍
Cache ID: 216::103

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!