lkeld/cve-2026-43499-pocWeaponized Proof-of-Concept für CVE-2026-43499 (GhostLock), einen Linux-Kernel-rtmutex-Fehler, der lokale Privilegieneskalation ermöglicht. Enthält Exploit-Ketten pro Distribution, technische Ausarbeitungen und Zuverlässigkeitstests.
Weaponisation-Forschung für CVE-2026-43499 (ghostlock).
der rtmutex-remove_water()-Proxy-Pfad-Bug, der die pi_blocked_on-Aufgabe eines Tasks in seinem eigenen gepoppten Kernel-Stack-Frame hängen lässt.
Die Bug-Klasse und die ursprüngliche Exploit-Strategie stammen von nebusec (deren Write-up hier)
alles in diesem Repo ist meine eigene Arbeit pro Distribution:
jede Kernel-Familie benötigt materiell unterschiedliche Primitive, und genau das macht das so interessant.
Der Auslöser von Ghostlock ist vollständig ohne Privilegien möglich (drei Futexe, zwei Threads und keine Namespaces). Der Prozess, den hängenden Zeiger in Root zu verwandeln, ist der Punkt, an dem sich die Distributionen unterscheiden – das hängt von der Frame-Geometrie, den Mitigationen und davon ab, was „kontrollierte Bytes an einer bekannten Kernel-Adresse“ überhaupt bedeuten, alles ändert sich. Dieses Repo wird Ketten pro Ziel-Familie sammeln.
| Ziel | Kette | Staging | Status |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — Physmap-Alias-Seite + auxv-Painter + sched_setscheduler-Walk | Root-im-Namespace (privilegierter Container) | funktionsfähig, 40/40 Stresstest auf sauberen Boots |
RHEL/CentOS 7 — 3.10.0-693.el7 | gleiche Kette, gemessene Frame-Geometrie | gleich | Komponenten 10/10 validiert; nur noch ein Stresstest ausstehend |
siehe WRITEUP.md in jedem Unterverzeichnis für die vollständige technische Analyse, die Root-Cause, warum die Standard-Kette aus der 6.x-Ära nicht übertragbar ist,
die Primitive-Erkenntnisse, was ich stattdessen gebaut habe, gemessene Frame-Geometrien und zuverlässigkeitsbezogene Daten.
wo es schwierig wird – der Walk validiert das ->lock des gefälschten Waiters gegen das Lock, das er gefunden hat (BUG_ON(w->lock != lock) auf 3.10), also brauchst du Fake-Strukturen in kernel-adressierbarem Speicher an einer Adresse, die du kennen würdest. Das unterscheidet sich stark pro Kernel (der CPU-Entry-Area-Trick aus der 6.x-Ära, den nebusec nutzte, existiert auf 3.10 nicht, el7 randomisiert die direkte Basiskarte, usw.). Jedes Write-up dokumentiert seine eigene Antwort.
der Bug und der Auslöser: du brauchst keine Privilegien, keine User-Namespaces, nichts. jeder lokale Benutzer funktioniert.
jede Weaponisation gibt ihr eigenes Staging an in ihrem Write-up. Die el7-Kette ist von Root-im-Namespace gestaged (in der Praxis: jede RCE in einen privilegierten Container – dies wurde von einer MYSQL-Instanz über ihren UDF-Plugin-Pfad validiert, was eine sehr typische Position ist). Die Kernel-seitige Arbeit nach dem Staging nutzt nur:
/proc/self/pagemap mit echten PFNs (in-ns CAP_SYS_ADMIN)/proc/kcore (in-ns CAP_SYS_RAWIO auf el7)/proc/kallsyms unmaskiert (kptr_restrict=0 oder CAP_SYSLOG)Keines davon ist die Schwachstelle selbst, es sind nur die Staging-Komfortfunktionen, die für Info-Leaks einstehen, die ich noch bauen muss.
Auf el7 speziell ist eine vollständig unprivilegierte Kette aus strukturellen Gründen blockiert (das 3.10-BUG_ON, kein CEA, kein statisches Fake-Lock-Paar im .data des Kernels, Pagemap-PFN-Gating).
Das el7-Write-up enthält die vollständige Analyse und die Forschungsrichtungen, hauptsächlich ein Head-Adress-Info-Leak-Primitiv.
panic_on_oops=1-Hosts verursacht ein falscher Walk einen Panic und führt zu einer toten Maschine, also behandle es als Teil deines Bedrohungsmodells beim Testen.el7/
WRITEUP.md vollständiges technisches Write-up für die el7-Kette
ghostlock_el7.c Single-File-PoC für beide getesteten Kernel
3bfdc63936dd („rtmutex: Use waiter::task instead of current in
remove_waiter()“); NPD-Folge-Update 40a25d59e85b