lkeld/cve-2026-43499-pocArme de preuve de concept pour CVE-2026-43499 (GhostLock), un bug du rtmutex du noyau Linux permettant une élévation locale de privilèges. Inclut des chaînes d'exploitation par distribution, des analyses techniques et des tests de fiabilité.
Recherche d'armement pour CVE-2026-43499 (ghostlock).
le bug du chemin proxy remove_water() de rtmutex qui laisse le pi_blocked_on d'une tâche suspendu dans sa propre pile de noyau éjectée.
La classe de bug et la stratégie d'exploit originale sont créditées à nebusec (leur analyse ici)
tout ce qui se trouve dans ce dépôt est mon propre travail par distribution :
chaque famille de noyau nécessite des primitives sensiblement différentes et c'est ce qui rend cela si intéressant.
Le déclencheur de Ghostlock est totalement non privilégié (trois futexes, deux threads et aucun namespace). Le processus qui transforme le pointeur suspendu en root est là où chaque distribution diverge, cela dépend de la géométrie des frames, des mitigations, et de ce que « octets contrôlés à une adresse noyau connue » signifie réellement, tout change. Ce dépôt collectera les chaînes par famille cible.
| Cible | Chaîne | Staging | Statut |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — page physmap-alias + peintre auxv + marche sched_setscheduler | root-dans-namespace (conteneur privilégié) | fonctionnel, test de stress 40/40 sur démarrages propres |
RHEL/CentOS 7 — 3.10.0-693.el7 | même chaîne, géométrie de frame mesurée | identique | composants validés 10/10 ; test de stress en attente |
voir le WRITEUP.md de chaque sous-répertoire pour l'analyse technique complète, la cause racine, pourquoi la chaîne standard de l'ère 6.x ne se transfère pas,
les découvertes de primitives, ce que j'ai construit à la place, les géométries de frame mesurées, et les données liées à la fiabilité.
là où les choses deviennent difficiles - la marche valide le ->lock du waiter forgé contre le verrou trouvé via (BUG_ON(w->lock != lock) sur 3.10), donc vous avez besoin de fausses structures dans une mémoire adressable par le noyau à une adresse que vous connaîtriez. c'est ce qui diffère énormément selon le noyau (l'astuce de la zone d'entrée CPU de l'ère 6.x utilisée par nebusec n'existe pas sur 3.10, el7 randomise la carte de base directe, etc.). Chaque analyse documente sa propre réponse.
le bug et le déclencheur : vous n'avez besoin d'aucun privilège, d'aucun namespace utilisateur, de rien. n'importe quel utilisateur local fonctionne.
chaque armement indique son propre staging dans son analyse. La chaîne el7 est stagée depuis root-dans-namespace (en pratique : n'importe quelle RCE dans un conteneur privilégié - cela a été validé depuis une instance MYSQL via son chemin de plugin UDF, qui est une position très typique). Le travail côté noyau après le staging utilise uniquement :
/proc/self/pagemap avec de vrais PFN (CAP_SYS_ADMIN dans le namespace)/proc/kcore (CAP_SYS_RAWIO dans le namespace sur el7)/proc/kallsyms non masqué (kptr_restrict=0 ou CAP_SYSLOG)Aucun de ceux-ci n'est la vulnérabilité elle-même, ce ne sont que les commodités de staging qui remplacent les fuites d'informations que je n'ai pas encore construites.
Sur el7 spécifiquement, une chaîne totalement non privilégiée est bloquée pour des raisons structurelles (le BUG_ON de 3.10, pas de CEA, pas de paire de faux verrous statiques dans le .data du noyau, le filtrage PFN de pagemap)
L'analyse el7 contient l'analyse complète et les directions de recherche, principalement une primitive de fuite d'informations d'adresse de tête
panic_on_oops=1, une mauvaise marche provoquera un panic et une machine morte, donc traitez-le comme un paramètre faisant partie de votre modèle de menace lors des testsel7/
WRITEUP.md analyse technique complète pour la chaîne el7
ghostlock_el7.c poc fichier unique pour les deux noyaux testés
3bfdc63936dd (« rtmutex : Utiliser waiter::task au lieu de current dans
remove_waiter() ») ; suivi NPD 40a25d59e85b