GhostLock: 15-летняя уязвимость use-after-free в ядре Linux, за которую Google заплатил $92 337

GhostLock (CVE-2026-43499), уязвимость типа use-after-free в ядре Linux, обнаруженная исследовательской командой VEGA. Она присутствует во всех крупных дистрибутивах Linux начиная с версии ядра 2.6.39 (2011 год) и вплоть до исправления в версии 7.1, выпущенного в апреле 2026 года, то есть больше 15 лет. Для срабатывания не нужны особые настройки ядра или привилегии: достаточно опции CONFIG_FUTEX_PI=y, которая включена по умолчанию почти везде. Исследователи довели эксплойт до стабильности 97% и продемонстрировали как повышение привилегий до root, так и побег из контейнера. Google выплатил за находку $92 337 в рамках программы вознаграждений kernelCTF.
Баг находится в функции remove_waiter() в файле kernel/locking/rtmutex.c. Она появилась в 2011 году вместе с переработкой алгоритма приоритетного наследования (PI) и была исправлена только в апреле 2026 года. Изначально функция писалась для одного сценария: поток блокируется сам и сам же убирает за собой запись, поэтому она обнуляет указатель current->pi_blocked_on, считая, что текущий выполняющийся поток (current) и есть тот самый ожидающий поток. Но механизм Requeue-PI (системный вызов futex с флагом FUTEX_CMP_REQUEUE_PI) использует ту же функцию для отката по цепочке от имени ДРУГОГО, спящего потока, и тогда current оказывается потоком, который инициировал перестановку в очереди, а не самим ожидающим. В итоге remove_waiter() обнуляет указатель не у того потока: настоящий ожидающий поток просыпается и возвращается в пользовательское пространство с "висящим" указателем pi_blocked_on, который указывает на уже освобождённый (вытолкнутый со стека) кадр памяти ядра. Любой последующий обход цепочки приоритетного наследования через этот поток разыменовывает мусорный указатель. Проблема незаметна для инструмента отладки блокировок lockdep, он проверяет лишь то, что блокировка pi_lock вообще удерживается, но не то, чья именно это блокировка.
Чтобы вызвать уязвимый откат, атакующий выстраивает цикл зависимостей из трёх потоков и трёх futex-слов, который приводит к обнаружению мнимого взаимного блокирования (-EDEADLK) и срабатыванию бажного отката. Дальше, вызывая prctl(PR_SET_MM, PR_SET_MM_MAP...) (подойдут и другие системные вызовы с крупными управляемыми буферами на стеке, clone, setsockopt, pselect, keyctl), атакующий кладёт контролируемые байты точно поверх освобождённого кадра стека, подделывая структуру rt_mutex_waiter. Гонку ускоряют параллельным вызовом fallocate(PUNCH_HOLE) над файлом в памяти (memfd), который растягивает окно копирования данных из пользовательского пространства. Адреса ядра (обход рандомизации адресного пространства, KASLR) утекают через побочный канал по времени выполнения инструкции prefetch, а фиксированный известный адрес для размещения поддельных структур и ROP-цепочки находят через прямое отображение области CPU entry area (CEA), её физическое смещение остаётся неизменным, даже когда виртуальный адрес CEA стали рандомизировать начиная с ядра версии 6.2. Итоговая управляемая запись перезаписывает элемент таблицы функций inet6_protos[IPPROTO_UDP], что даёт перехват потока управления при обработке обратно-петлевого (loopback) IPv6 UDP-пакета; финальная запись переключает биты режима у core_pattern, после чего остаток повышения привилегий выполняется уже полностью в пользовательском пространстве.
Авторы отмечают, что в теории технику утечки адресов через prefetch можно применить на любом процессоре с этой инструкцией и без включённой изоляции таблиц страниц ядра (KPTI), но на практике это преимущественно техника для x86; в тестовых образах kernelCTF KPTI отключена. Отдельным постом команда обещает разобрать эксплуатацию GhostLock на Android, с обходом и ASLR, и защиты целостности потока управления (CFI). Код proof-of-concept опубликован в открытом доступе.
Ключевые факты
- GhostLock (CVE-2026-43499), use-after-free в ядре Linux, существовал с версии 2.6.39 (2011 год) до исправления в 7.1 (апрель 2026), больше 15 лет.
- Нужна только опция CONFIG_FUTEX_PI=y, включённая по умолчанию почти везде; особые привилегии или конфигурация не требуются.
- Эксплойт стабилен на 97%, даёт непривилегированному локальному пользователю root и позволяет сбежать из контейнера.
- Причина, функция remove_waiter() в rtmutex.c при откате Requeue-PI futex обнуляет указатель pi_blocked_on не у того потока, оставляя висящий указатель на освобождённый кадр стека ядра.
- Google выплатил исследователям из VEGA $92 337 через программу kernelCTF; PoC-код опубликован в открытом доступе.
Почему это важно
Это редкий случай критичной уязвимости, которая пряталась в самом ядре Linux более 15 лет и не требует ни особых привилегий, ни нестандартной конфигурации, только опцию, включённую практически везде по умолчанию. Она даёт не просто локальное повышение привилегий, а ещё и побег из контейнера, что критично для облачных провайдеров, хостингов и любых мультитенантных сред, где изоляция через контейнеры, основная линия защиты.
Кому это важно
В первую очередь, администраторам Linux-серверов, инженерам эксплуатации облачной и контейнерной инфраструктуры (Kubernetes, VPS-хостинги, shared-хостинг), сопровождающим дистрибутивов и специалистам по безопасности. Актуально для любой организации, где на общих серверах или в контейнерах выполняется код разных пользователей или клиентов.
Как это применить
Нужно обновить ядро Linux до версии с исправлением (7.1 или бэкпорт коммита с фиксом) на всех системах, особенно многопользовательских и с контейнерной изоляцией. Стоит свериться с бюллетенями безопасности своего дистрибутива на предмет бэкпорта патча в LTS-ветки и, где возможно, ограничить или замониторить использование Requeue-PI futex до установки обновления.
Можно ли доверять
Материал, технический отчёт исследовательской команды VEGA на её сайте nebusec.ai, с указанием конкретного CVE, точных хешей коммитов ядра (появления и исправления бага) и опубликованным кодом proof-of-concept. Находка подтверждена реальной выплатой Google в размере $92 337 по программе kernelCTF, это независимое подтверждение через сторонний bug bounty. Уровень детализации и проверяемость (конкретные строки кода, коммиты) говорят о высокой достоверности.
Риски и подводные камни
Переданный для пересказа текст обрывается в середине технического раздела про построение примитива произвольной записи, поэтому часть деталей финальной сборки эксплойта в пересказ не попала. Авторы также анонсировали отдельный, ещё не опубликованный пост об эксплуатации GhostLock на Android с обходом ASLR и CFI. Публикация рабочего PoC-кода повышает риск быстрой адаптации эксплойта злоумышленниками для непропатченных систем, несмотря на техническую сложность самой атаки.
«Проблема ускользает от lockdep, он проверяет лишь то, что блокировка pi_lock вообще удерживается, но не то, чья именно это блокировка.»
— из технического отчёта команды VEGA (nebusec.ai) о GhostLock