lkeld/cve-2026-43499-pocArma de prova de conceito para CVE-2026-43499 (GhostLock), uma falha no rtmutex do kernel Linux que permite escalonamento local de privilégios. Inclui cadeias de exploração por distribuição, documentação técnica e testes de confiabilidade.
Pesquisa de armamento para CVE-2026-43499 (ghostlock).
o bug do caminho proxy remove_water() do rtmutex que deixa o pi_blocked_on de uma tarefa pendurado no próprio frame de pilha do kernel que foi removido.
A classe do bug e a estratégia original do exploit são creditadas a nebusec (o write-up deles aqui)
tudo neste repositório é meu próprio trabalho por distribuição:
cada família de kernel precisa de primitivas materialmente diferentes e é isso que torna tudo tão interessante.
O gatilho do Ghostlock é completamente sem privilégios (três futexes, duas threads e sem namespaces). O processo de transformar o ponteiro pendurado em root é onde cada uma das distros diverge; isso se resume à geometria do frame, mitigações e ao que "bytes controlados em um endereço de kernel conhecido" significam — tudo muda. Este repositório vai coletar cadeias por família alvo.
| Alvo | Cadeia | Staging | Status |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — página de alias physmap + pintor auxv + caminhada sched_setscheduler | root-no-namespace (container privilegiado) | funcionando, teste de estresse 40/40 em boots limpos |
RHEL/CentOS 7 — 3.10.0-693.el7 | mesma cadeia, geometria de frame medida | o mesmo | componentes validados 10/10; apenas aguardando um teste de estresse |
veja o WRITEUP.md de cada subdiretório para a análise técnica completa, a causa raiz, por que a cadeia padrão da era 6.x não é transferível,
as descobertas de primitivas, o que eu construí em vez disso, as geometrias de frame medidas e os dados relacionados à confiabilidade.
onde as coisas ficam difíceis — a caminhada valida o ->lock do waiter forjado contra o lock que encontrou (BUG_ON(w->lock != lock) no 3.10), então você precisa de estruturas falsas em memória endereçável pelo kernel em um endereço que você conheceria. é isso que difere drasticamente por kernel (o truque da área de entrada da CPU da era 6.x que a nebusec utilizou não existe no 3.10, o el7 randomiza o mapa base direto, etc.). Cada write-up documenta sua própria resposta.
o bug e o gatilho: você não precisa de privilégios, nem de user namespaces, nada. qualquer usuário local funciona.
cada armamento declara seu próprio staging no seu write-up. A cadeia el7 é encenada a partir de root-no-namespace (na prática: qualquer RCE em um container privilegiado — isso foi validado a partir de uma instância MYSQL via seu caminho de plugin UDF, que é uma posição muito típica de se estar). O trabalho no lado do kernel após o staging usa apenas:
/proc/self/pagemap com PFNs reais (in-ns CAP_SYS_ADMIN)/proc/kcore (in-ns CAP_SYS_RAWIO no el7)/proc/kallsyms sem máscara (kptr_restrict=0 ou CAP_SYSLOG)Nenhum desses é a vulnerabilidade em si; são apenas as conveniências de staging que substituem os vazamentos de informação que ainda não construí.
No el7 especificamente, uma cadeia totalmente sem privilégios é bloqueada por razões estruturais (o BUG_ON do 3.10, sem CEA, sem par de lock falso estático no .data do kernel, gating de PFN do pagemap)
O write-up do el7 tem a análise completa e as direções de pesquisa, principalmente uma primitiva de vazamento de informação de endereço de cabeça
panic_on_oops=1, uma caminhada errada causará um panic e resultará em uma máquina morta, então trate isso como uma configuração parte do seu modelo de ameaça ao testarel7/
WRITEUP.md write-up técnico completo para a cadeia el7
ghostlock_el7.c poc de arquivo único para ambos os kernels testados
3bfdc63936dd ("rtmutex: Use waiter::task instead of current in
remove_waiter()"); acompanhamento de NPD 40a25d59e85b