lkeld/cve-2026-43499-poc# Weaponized proof-of-concept per CVE-2026-43499 (GhostLock), un bug del kernel Linux relativo a rtmutex che consente l'escalation locale dei privilegi. Include catene di exploit per singola distribuzione, documentazione tecnica e test di affidabilità.
Ricerca di weaponisation per CVE-2026-43499 (ghostlock).
il bug del percorso proxy remove_water() di rtmutex che lascia il pi_blocked_on di un task appeso nel proprio stack frame kernel popato.
La classe del bug e la strategia di exploit originale sono da attribuire a nebusec (il loro write-up qui)
tutto in questo repo è il mio lavoro per-distribuzione:
ogni famiglia di kernel richiede primitive materialmente diverse ed è questo che lo rende così interessante.
Il trigger di Ghostlock è completamente non privilegiato (tre futex, due thread e nessun namespace). Il processo per trasformare il puntatore appeso in root è dove ogni distro diverge; tutto dipende dalla geometria dello stack frame, dalle mitigazioni e da cosa significhi "byte controllati a un indirizzo kernel noto", che cambiano tutti. Questo repo raccoglierà le chain per famiglia di target.
| Target | Chain | Staging | Stato |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — pagina physmap-alias + painter auxv + walk sched_setscheduler | root-in-namespace (container privilegiato) | funzionante, stress test 40/40 su boot puliti |
RHEL/CentOS 7 — 3.10.0-693.el7 | stessa chain, geometria dello stack frame misurata | stessa | componenti validati 10/10; in attesa solo di uno stress test |
vedi il WRITEUP.md di ogni sottodirectory per l'analisi tecnica completa, la root cause, perché la chain standard dell'era 6.x non si trasferisce,
i risultati sulle primitive, cosa ho costruito al suo posto, le geometrie dello stack frame misurate e i dati relativi all'affidabilità.
dove le cose si fanno difficili - il walk valida il ->lock del waiter forgiato contro il lock trovato tramite esso (BUG_ON(w->lock != lock) su 3.10), quindi servono strutture fake in memoria indirizzabile dal kernel a un indirizzo che conosceresti. questo è ciò che varia enormemente per kernel (il trucco dell'area di ingresso CPU dell'era 6.x usato da nebusec non esiste su 3.10, el7 randomizza la mappa base diretta, ecc.). Ogni writeup documenta la propria risposta.
il bug e il trigger: non servono privilegi, niente user namespaces, niente. qualsiasi utente locale funziona.
ogni weaponisation dichiara il proprio staging nel suo writeup. La chain el7 è staged da root-in-namespace (in pratica: qualsiasi RCE in un container privilegiato - questo è stato validato da un'istanza MYSQL tramite il suo percorso plugin UDF, che è una posizione molto tipica in cui trovarsi). Il lavoro lato kernel dopo lo staging usa solo:
/proc/self/pagemap con PFN reali (in-ns CAP_SYS_ADMIN)/proc/kcore (in-ns CAP_SYS_RAWIO su el7)/proc/kallsyms non mascherato (kptr_restrict=0 o CAP_SYSLOG)Nessuno di questi è la vulnerabilità in sé, sono solo le comodità di staging che fanno da sostituto per le info leak che devo ancora costruire.
Su el7 in particolare, una chain completamente non privilegiata è bloccata per ragioni strutturali (il BUG_ON del 3.10, niente CEA, nessuna coppia fake-lock statica nel .data del kernel, gating PFN di pagemap)
Il writeup el7 ha l'analisi completa e le direzioni di ricerca, principalmente una primitiva di info-leak dell'indirizzo head
panic_on_oops=1, un walk sbagliato causerà un panic e una macchina morta, quindi trattalo come un'impostazione parte del tuo modello di minaccia quando testiel7/
WRITEUP.md writeup tecnico completo per la chain el7
ghostlock_el7.c poc in un singolo file per entrambi i kernel testati
3bfdc63936dd ("rtmutex: Use waiter::task instead of current in
remove_waiter()"); follow-up NPD 40a25d59e85b