lkeld/cve-2026-43499-pocОружиезированный proof-of-concept для CVE-2026-43499 (GhostLock) — ошибки в rtmutex ядра Linux, позволяющей локальное повышение привилегий. Включает цепочки эксплойтов для каждого дистрибутива, технические описания и тестирование надёжности.
Исследование по вооружению для CVE-2026-43499 (ghostlock).
ошибка пути прокси remove_water() в rtmutex, из-за которой pi_blocked_on задачи остаётся висеть в её собственном вытесненном кадре стека ядра.
Класс ошибки и оригинальная стратегия эксплойта принадлежат nebusec (их статья здесь)
всё в этом репозитории — моя собственная работа по каждому дистрибутиву:
каждому семейству ядер нужны принципиально разные примитивы, и именно это делает задачу такой интересной.
Триггер Ghostlock полностью непривилегированный (три фьютекса, два потока и никаких неймспейсов). Процесс превращения висящего указателя в root — вот где дистрибутивы расходятся: геометрия кадров, митигации и то, что вообще означает «контролируемые байты по известному адресу ядра», — всё меняется. Этот репозиторий будет собирать цепочки для каждого целевого семейства.
| Цель | Цепочка | Стадия | Статус |
|---|---|---|---|
RHEL/CentOS 7 — 3.10.0-1160.102.1.el7 | el7/ — physmap-алиас страницы + auxv-раскраска + обход через sched_setscheduler | root-в-неймспейсе (привилегированный контейнер) | работает, 40/40 стресс-тестов на чистых загрузках |
RHEL/CentOS 7 — 3.10.0-693.el7 | та же цепочка, измеренная геометрия кадров | то же | компоненты проверены 10/10; осталось только стресс-тестирование |
см. WRITEUP.md в каждом подкаталоге для полного технического анализа, первопричины, почему стандартная цепочка эпохи 6.x не переносится,
находок по примитивам, того, что я построил вместо этого, измеренных геометрий кадров и данных о надёжности.
где возникают сложности — обход проверяет поддельный ->lock ожидающего против блокировки, найденной через него (BUG_ON(w->lock != lock) на 3.10), поэтому нужны фейковые структуры в адресуемой ядром памяти по адресу, который вы знаете. именно это сильно различается между ядрами (трюк с областью входа CPU эпохи 6.x, который использовал nebusec, не существует на 3.10, el7 рандомизирует прямую базовую карту и т.д.). Каждая статья документирует свой ответ.
ошибка и триггер: не нужны никакие привилегии, никакие пользовательские неймспейсы, ничего. подойдёт любой локальный пользователь.
каждое вооружение указывает свою собственную стадию в своей статье. Цепочка el7 разворачивается из root-в-неймспейсе (на практике: любой RCE в привилегированный контейнер — это было проверено из экземпляра MYSQL через путь его UDF-плагина, что является очень типичной позицией). Работа на стороне ядра после стадии использует только:
/proc/self/pagemap с реальными PFN (внутри неймспейса CAP_SYS_ADMIN)/proc/kcore (внутри неймспейса CAP_SYS_RAWIO на el7)/proc/kallsyms без маскирования (kptr_restrict=0 или CAP_SYSLOG)Ни одно из них не является самой уязвимостью, это просто удобства стадии, заменяющие утечки информации, которые мне ещё предстоит построить.
Именно на el7 полностью непривилегированная цепочка заблокирована по структурным причинам (BUG_ON на 3.10, нет CEA, нет статической пары фейковых блокировок в .data ядра, ограничение PFN в pagemap)
В статье по el7 есть полный анализ и направления исследований, в основном примитив утечки информации по адресу заголовка
panic_on_oops=1 неправильный обход вызовет панику и приведёт к мёртвой машине, поэтому рассматривайте эту настройку как часть вашей модели угроз при тестированииel7/
WRITEUP.md полная техническая статья по цепочке el7
ghostlock_el7.c однофайловый PoC для обоих протестированных ядер
3bfdc63936dd ("rtmutex: Use waiter::task instead of current in
remove_waiter()"); последующее исправление NPD 40a25d59e85b