Опубликованные детали по Bad Epoll быстро вывели уязвимость в число самых неприятных новостей недели: ошибка в ядре Linux получила 7,8 балла по CVSS и позволяла локальному непривилегированному процессу добраться до root. Под удар попали десктопы, серверы и часть Android-устройств.

Проблема звучит как классическая история про редкий баг в ядре, но на практике она опаснее обычного падения службы. Если злоумышленник уже получил запуск кода на машине, Bad Epoll открывал ему дорогу к полному контролю над системой.

Что именно сломалось в ядре Linux

Bad Epoll — это use-after-free, то есть обращение к уже освобождённой памяти. Ошибка возникала в механизме epoll, который Linux использует для отслеживания готовности файловых дескрипторов к вводу-выводу.

Сбой проявлялся при параллельном закрытии связанных дескрипторов. Один путь освобождал внутренний объект ядра, а другой продолжал к нему обращаться. Дальше исследователь смог извлечь данные из памяти ядра, перехватить поток исполнения и собрать рабочую цепочку для повышения привилегий.

Для сравнения: похожие дефекты в системных компонентах нередко всплывают и в других продуктах. Мы уже разбирали, как дыра в заголовке reverse proxy ударила по Gitea Docker, — там тоже ошибка на низком уровне быстро превращается в риск для всей инфраструктуры.

Чем Bad Epoll отличается от обычной «дыры»

Главная проблема здесь не только в самом баге, но и в условиях его срабатывания. Узкое «окно» гонки занимало лишь несколько машинных инструкций, поэтому случайно попасть в него было почти нереально.

Но исследователь сумел расширить это окно и довёл надёжность эксплоита до примерно 99 % на тестовых конфигурациях. Для атакующего это уже не теория, а практически повторяемый сценарий.

Ещё один неприятный момент — уязвимость можно было использовать даже из песочницы рендерера Chrome. Такая среда обычно сильно сужает набор доступных атак, но Bad Epoll оказался достаточно сильным, чтобы выйти за эти рамки. Если вам интересна общая логика таких цепочек, посмотрите разбор как строят базы угроз для SOC и LLM-агентов.

Какие варианты защиты есть у пользователей и администраторов

Первый и самый надёжный шаг — установить обновление ядра с бэкпортом исправления или апстрим-коммит a6dc643c6931. Авторы сообщили, что обходных мер нет: без патча уязвимыми считаются версии ядра 6.4 и новее.

Второй вариант — проверить, не попадает ли ваша система в список рискованных конфигураций. На практике это касается серверов на свежих ядрах, рабочих станций с актуальными дистрибутивами и Android-устройств на затронутых сборках.

Третий путь — снизить ущерб на уровне самой среды. Ограничение локальных прав, жёсткая изоляция сервисов и аккуратная работа с песочницами не закрывают Bad Epoll, но помогают не дать одиночному процессу слишком много свободы.

Отдельно стоит помнить о защите трафика в открытых сетях. Если вы часто подключаетесь из кафе, отеля или аэропорта, имеет смысл пользоваться инструментом для шифрования трафика в публичных сетях, чтобы не раздавать лишние данные посторонним.

Кому нужно реагировать быстрее всего

Администраторам серверов на Linux — в первую очередь. Для них одна локальная точка входа может превратиться в полный захват машины, а дальше — в доступ к данным, ключам и внутренним сервисам.

Владельцам Android-устройств тоже стоит следить за обновлениями производителя. По сообщениям исследователя, проблема подтверждена на Pixel 10 с ядром Linux 6.6, а часть более старых сборок на 6.1 от неё не затронута.

Обычным пользователям настольных систем не стоит считать себя в безопасности только потому, что они не администрируют сервер. Если на устройстве есть уязвимое ядро и злоумышленник уже запустил код локально, последствия могут быть очень тяжёлыми.

Что делать прямо сейчас

  • Проверить версию ядра Linux на рабочих станциях, серверах и Android-сборках.
  • Установить обновления дистрибутива и патчи производителя без откладывания.
  • Уточнить, есть ли в репозитории бэкпорт исправления для CVE-2026-46242.
  • Ограничить запуск непроверенных локальных процессов и лишние права сервисов.
  • Для публичных сетей использовать отдельные защитные инструменты и не передавать чувствительные данные без шифрования.
  • Следить за сообщениями вендора, если устройство пока не получило фикс.
Поделиться: