Bad Epoll 0-Day: эксплойт ядра Linux и Android через гонку состояний

Любой технический руководитель, управляющий парком Linux-хостов или выпускающий Android-приложение с WebView, должен воспринимать раскрытие этой недели как разговор о бюджете, а не как задачу на установку патча. Недавно опубликованная уязвимость ядра под названием Bad Epoll даёт непривилегированному локальному пользователю надёжный путь к root на серверах, десктопах и Android-устройствах, и она достижима изнутри sandbox-процесса renderer Chrome. Такое сочетание меняет модель угроз для всех, чей продукт связан с браузером или Android-устройствами.

Техническая история интересна. Деловая история — кто несёт расходы на реагирование — это то, о чём стоит спорить внутри компании в этом месяце.

Ключевые детали

Уязвимость, отслеживаемая как CVE-2026-46242, представляет собой use-after-free в ep_remove() — пути завершения работы в подсистеме epoll ядра Linux. Как сообщает CyberSecurityNews, уязвимость очищает file->f_ep под file->f_lock, но продолжает использовать объект файла внутри критической секции во время hlist_del_rcu() и spin_unlock(). Параллельный вызов __fput() может обнаружить временный NULL, пропустить eventpoll_release_file() и перейти напрямую к f_op->release, освобождая struct eventpoll, который всё ещё используется.

Поскольку struct file помечен как SLAB_TYPESAFE_BY_RCU, освобождённый слот может быть переиспользован через alloc_empty_file(). Это даёт атакующему возможность вызвать kmem_cache_free() против неправильного slab-кэша. Исследователь Чон Чжэён отправил уязвимость как zero-day в программу kernelCTF от Google, которая платит от $71 337 и выше за работающие эксплойты ядра Linux.

Сам эксплойт представляет собой настоящее мастерство. Он использует четыре объекта epoll, объединённых в две пары; закрытие одной пары запускает гонку, пока другая становится жертвой. Это превращает 8-байтовую UAF-запись в UAF на объекте файла через cross-cache атаку. Затем атакующий получает произвольное чтение памяти ядра через /proc/self/fdinfo и перехватывает поток управления с помощью ROP-цепочки для получения root shell. Окно гонки составляет примерно шесть инструкций. Эксплойт Чона расширяет его, повторяет попытки без паник ядра и демонстрирует около 99% надёжности на протестированных целях.

Обходного пути не существует. Epoll — это базовый компонент ядра, который нельзя отключить или выгрузить, и именно поэтому уязвимость даёт root как на Android, так и на серверах. Администраторы должны либо применить патч из upstream, либо ждать, пока их дистрибутив выполнит бэкпорт.

Почему это важно для команд безопасности

Ключевой архитектурный факт: Bad Epoll достижим изнутри sandbox-процесса renderer Chrome. В цепочке с уязвимостью renderer это обеспечивает полное выполнение кода в ядре с hostile веб-страницы. Для любой команды, выпускающей Android-продукт, десктопное приложение на Electron или поверхность с встроенным Chromium, это разница между «уязвимостью ядра, которую нужно закрыть» и «примитивом remote-to-root, который нужно моделировать».

Кадровые последствия неудобны. Большинство команд безопасности у финтех-компаний серии B и операторов iGaming среднего размера не имеют в штате инженера, разбирающегося в ядре. У них есть специалисты по appsec общего профиля и SOC-контракт. Когда появляется такая уязвимость, вопрос о том, кто читает патч, проверяет бэкпорт и подписывает пересборку мобильного приложения, достаётся тому, кто поднимет руку. Это кадровый пробел, а не инструментальный, и ни один EDR-вендор не закроет его за вас.

Регуляторные риски варьируются в зависимости от отрасли, но они реальны. Лицензированные операторы iGaming, работающие с Android-приложениями для игроков на регулируемых рынках, имеют таймеры уведомления о нарушениях, которые начинают отсчёт с момента обнаружения, а не с момента эксплуатации. Финтех-компании с позицией SOC 2 или ISO 27001 должны будут задокументировать временну́ю шкалу реагирования. Компании по хранению криптоактивов, использующие защищённые Linux-хосты, получают худшее из обоих миров: уязвимость ядра на серверной стороне плюс поверхности мобильного подписания на клиентской стороне.

CFO любого финтех-компании, ориентированной на потребителей, должен на этой неделе спросить своего VP Engineering, какой процент Android-устройств находится на ветке ядра, которая реально получит своевременный бэкпорт, и сколько стоит принудительное обновление приложения до цикла OEM. Этот показатель окажется хуже, чем кто-либо ожидает. Задержка патчей ядра Android всегда была неприглядной стороной модели мобильной безопасности, и именно такой тип уязвимостей остаётся незакрытым на устройствах среднего класса от шести до девяти месяцев.

Влияние на отрасль

В раскрытии есть вторая, более тихая история, которая, на мой взгляд, важнее для распределения бюджетов безопасности в следующие двенадцать месяцев. Один коммит ядра 2023 года внёс две отдельные гонки состояний в один и тот же путь кода epoll длиной 2500 строк. Первую, CVE-2026-43074, обнаружила модель Mythos от Anthropic. Mythos пропустила Bad Epoll — более трудновыявимую вторую гонку — вероятно, потому что окно timing составляет всего около шести инструкций, а уязвимость редко срабатывает KASAN — основной детектор ошибок памяти ядра.

Вчитайтесь внимательно. Аудит ядра с помощью ИИ уже достаточно хорош, чтобы находить настоящие гонки состояний в коде производственного ядра. Он ещё недостаточно хорош, чтобы находить те, которые не оставляют следов во время выполнения. Это имеет прямые последствия для разговора о покупке или самостоятельной разработке, который сейчас ведётся в каждой платформенной организации. Если вы CTO, которому предлагают продукт для AI-аудита безопасности, честное позиционирование таково: он поймает класс уязвимостей, которые инструментирование уже выявляет, и пропустит класс, требующий терпеливой человеческой интуиции в отношении slab-кэшей и RCU-семантики. Устанавливайте цену соответственно.

Для вендорского рынка Bad Epoll — это напоминание о том, что программы вознаграждений в стиле kernelCTF — это недооценённая страховка. Google заплатил минимум $71 337 за уязвимость, которая в связке с эксплойтом renderer продавалась бы в разы дороже на наступательном рынке. Любая платформенная компания, чей продукт зависит от целостности Linux или Android, должна задаться вопросом: откалиброваны ли их собственные лимиты вознаграждений к реальной стоимости альтернативы. У большинства — нет.

Вендоры дистрибутивов также выглядят медленными. Первая попытка патча от мейнтейнеров не решила проблему полностью, и корректное исправление появилось почти через два месяца после первоначального раскрытия. Именно в этом окне ваш план реагирования на инциденты должен уметь выживать — а не в теоретическом интервале нулевого дня.

За чем следить

Три сигнала стоит отслеживать в следующем квартале. Во-первых, как быстро крупные OEM-производители Android внедрят бэкпорт в свои ежемесячные бюллетени безопасности. Исторически разброс велик, и эта уязвимость покажет, кто из вендоров реально инвестировал в конвейеры патчирования ядра, а кто по-прежнему перекладывает всё на партнёров по кремнию и надеется на лучшее.

Во-вторых, следите за неизбежным публичным выпуском эксплойта. Описание Чона детально, гонка хорошо охарактеризована, а 99% надёжности означает, что кто-то портирует его в модуль Metasploit до конца Q3. Именно тогда начинается оппортунистическое использование, и именно тогда эта уязвимость попадёт в каталог CISA KEV с жёстким федеральным дедлайном.

В-третьих, следите за тем, что Anthropic и её конкуренты опубликуют о проверке ядра с помощью ИИ. Если ответом на то, что Mythos пропустила Bad Epoll, станет модель второго поколения, специально настроенная на гонки с узким окном и уязвимости, невидимые для KASAN, экономика аудита ядра изменится быстро. Если нет — ожидайте, что рынок труда для специалистов по безопасности ядра останется жёстко ограниченным, а компенсация за этот набор навыков продолжит расти.

Командам, оценивающим расходы на безопасность в 2026 году, стоит сейчас задать себе вопрос: может ли их конвейер мобильных обновлений реально доставить патч ядра конечным пользователям в рамках окна, обещанного регуляторам? И если нет — сколько стоит устранить этот разрыв до того, как появится следующий Bad Epoll?

Ключевые выводы

• Bad Epoll (CVE-2026-46242) — это use-after-free при завершении работы Linux epoll, дающий root с ~99% надёжностью от непривилегированного локального пользователя; обходного пути нет, кроме применения upstream-патча.
• Уязвимость достижима из sandbox-процесса renderer Chrome, превращая любой RCE в renderer в полную цепочку выполнения кода ядра на Linux и Android.
• Уязвимость Android носит структурный характер: epoll нельзя отключить, а задержка патчей OEM оставит большую часть устройств уязвимой на месяцы.
• Аудит ядра с помощью ИИ нашёл родственную уязвимость (CVE-2026-43074), но пропустил Bad Epoll — полезная точка данных для тех, кто включает AI-инструменты безопасности в бюджет 2026 года.
• Выплата Google в $71 337 по программе kernelCTF — это нижняя граница, а не потолок; внутренние программы вознаграждений с более низкими лимитами недостаточно страхуют именно от этого класса уязвимостей.