В середине июня 2026 года в ядре Linux обнаружилась ошибка, получившая идентификатор CVE-2026-46331 и прозвище «pedit COW». Дыра живёт в подсистеме Traffic Control, а точнее — в модуле act_pedit и функции tcf_pedit_act(). Суть в классическом расчёте времени проверки и времени использования (TOCTOU) внутри логики Copy-on-Write: ядро сначала прикидывает границы私ной копии пакета, а потом уже на этапе исполнения часть ключей редактирования вычисляет смещения «на лету». Запись уходит мимо защищённой области и попадает прямо в общую страницу page-cache, которая представляет собой содержимое файла на диске. Так обычный непривилегированный пользователь получает примитив записи в памяти, причём в кэше страниц, а не на диске.
Атакующий выбирает цель — SetUID-root бинарник (например, /bin/su) — и через tc pedit отправляет специально сформированный пакет. Ядро «отравляет» страницу в памяти, подменяя байты внутри образа su. Затем жертва запускает этот бинарник, а на деле — модифицированный код из page-cache, и привет, root-shell. Главная хитрость: на диске ничего не меняется. Файл /bin/su остаётся в первозданном виде, поэтому AIDE, Tripwire, rpm -V и debsums показывают чистоту. Скомпрометирована только оперативная память.
Чтобы цепочка заработала, нужно совпадение двух вещей. Во-первых, модуль act_pedit должен быть загружаемым (проверяется через lsmod | grep act_pedit). Во-вторых, в системе должны работать непривилегированные пользовательские неймспейсы, дающие внутри namespace локальный CAP_NET_ADMIN, без которого обычный юзер не смог бы конфигурировать правила tc. В Red Hat Enterprise Linux 10 неймспейсы открыты по умолчанию, PoC-эксплойт отрабатывает стабильно. Версии RHEL 8 и 9 значатся в бюллетене как затронутые, а вот RHEL 7 в списке не фигурирует вовсе. У Debian картина такая: Trixie (13) уже получил патч через security-канал, а Bookworm (12) и Bullseye (11) остаются уязвимыми по состоянию на 25 июня. Ubuntu пометил уязвимыми все поддерживаемые релизы с 18.04 по 26.04, но в 26.04 AppArmor из коробки режет доступ к пользовательским неймспейсам, поэтому эксплойт в стандартной конфигурации не проходит. На 24.04 (Noble) приходится искать профили AppArmor, которые этот доступ разрешают.
Что делать прямо сейчас
Главный и обязательный шаг — установка пропатченного ядра и перезагрузка. Патч лёг в апстрим 16 июня, в тот же день, когда CVE получил номер. Уже через сутки появился публичный рабочий эксплойт, так что темп распространения максимальный. В зоне риска любые машины с несколькими локальными пользователями: CI/CD-раннеры, ноды Kubernetes, сборочные воркеры, лабораторные и учебные хосты.
Если сервису не нужны правила tc pedit, самый дешёвый способ закрыться — запретить загрузку модуля:
Альтернативный путь — отключить непривилегированные пользовательские неймспейсы. На RHEL: sysctl -w user.max_user_namespaces=0 (сохранить в /etc/sysctl.d/). На Debian и Ubuntu: sysctl -w kernel.unprivileged_userns_clone=0 (аналогично в /etc/sysctl.d/). У этого способа ощутимый побочный эффект: ломаются rootless-контейнеры (Podman, Docker в rootless-режиме), часть CI-песочниц и механизмы изоляции браузеров вроде Chrome и Firefox. Перед раскаткой стоит прогнать тесты.
Если эксплойт уже отработал, команда echo 3 > /proc/sys/vm/drop_caches сбрасывает отравленный кэш, но не закрывает уже полученный root-shell и не лечит ядро. Файловые системы целостности (FIM) бесполезны для обнаружения: диск чистый, агенты смотрят не туда, куда нужно. Любой инцидент требует полной ротации учётных данных и нормального форензик-обследования, а не «сбрасывания кэша и перезапуска».
Хронология и исторический контекст
Кривая истории раскрытия здесь такая. Ещё в конце мая исправление ушло в рассылку netdev, причём оформлено как «обычный патч против повреждения данных», без CVE, без security-тега и без упоминания безопасности. Детали, достаточные для эксплуатации, провисели публично несколько недель. 16 июня патч приняли в апстрим и присвоили CVE-2026-46331, а 17 июня появился PoC. К 25 июня Red Hat подтвердил уязвимость RHEL 8/9/10, Debian закрыл Trixie, а Ubuntu продолжал держать в списке все релизы.
CVE-2026-46331 вписывается в целое семейство похожих багов, связанных с порчей page-cache через «быстрые пути» ядра: Dirty Pipe (CVE-2022-0847), Copy Fail, DirtyClone (CVE-2022-25212), Dirty Frag. «pedit COW» отличается точкой входа — комбинация act_pedit и пользовательских неймспейсов с CAP_NET_ADMIN внутри namespace. Принципиальная мысль, которую подчёркивают исследователи: для таких дыр полагаться на сканеры и обновление правил слишком медленно — эксплойт появляется за сутки, и окно для атаки открывается задолго до того, как вендор разошлёт бюллетени.
Из всего этого вытекает простой практический вывод: на машинах, где есть хоть один лишний локальный пользователь, патч tcf_pedit_act() и перезагрузка должны случиться как можно скорее, а запрет act_pedit или пользовательских неймспейсов — первая линия обороны до того, как патч можно поставить.
Атакующий выбирает цель — SetUID-root бинарник (например, /bin/su) — и через tc pedit отправляет специально сформированный пакет. Ядро «отравляет» страницу в памяти, подменяя байты внутри образа su. Затем жертва запускает этот бинарник, а на деле — модифицированный код из page-cache, и привет, root-shell. Главная хитрость: на диске ничего не меняется. Файл /bin/su остаётся в первозданном виде, поэтому AIDE, Tripwire, rpm -V и debsums показывают чистоту. Скомпрометирована только оперативная память.
Чтобы цепочка заработала, нужно совпадение двух вещей. Во-первых, модуль act_pedit должен быть загружаемым (проверяется через lsmod | grep act_pedit). Во-вторых, в системе должны работать непривилегированные пользовательские неймспейсы, дающие внутри namespace локальный CAP_NET_ADMIN, без которого обычный юзер не смог бы конфигурировать правила tc. В Red Hat Enterprise Linux 10 неймспейсы открыты по умолчанию, PoC-эксплойт отрабатывает стабильно. Версии RHEL 8 и 9 значатся в бюллетене как затронутые, а вот RHEL 7 в списке не фигурирует вовсе. У Debian картина такая: Trixie (13) уже получил патч через security-канал, а Bookworm (12) и Bullseye (11) остаются уязвимыми по состоянию на 25 июня. Ubuntu пометил уязвимыми все поддерживаемые релизы с 18.04 по 26.04, но в 26.04 AppArmor из коробки режет доступ к пользовательским неймспейсам, поэтому эксплойт в стандартной конфигурации не проходит. На 24.04 (Noble) приходится искать профили AppArmor, которые этот доступ разрешают.
Что делать прямо сейчас
Главный и обязательный шаг — установка пропатченного ядра и перезагрузка. Патч лёг в апстрим 16 июня, в тот же день, когда CVE получил номер. Уже через сутки появился публичный рабочий эксплойт, так что темп распространения максимальный. В зоне риска любые машины с несколькими локальными пользователями: CI/CD-раннеры, ноды Kubernetes, сборочные воркеры, лабораторные и учебные хосты.
Если сервису не нужны правила tc pedit, самый дешёвый способ закрыться — запретить загрузку модуля:
Код Выделить
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.confПосле этого уязвимый код просто нельзя вызвать. Альтернативный путь — отключить непривилегированные пользовательские неймспейсы. На RHEL: sysctl -w user.max_user_namespaces=0 (сохранить в /etc/sysctl.d/). На Debian и Ubuntu: sysctl -w kernel.unprivileged_userns_clone=0 (аналогично в /etc/sysctl.d/). У этого способа ощутимый побочный эффект: ломаются rootless-контейнеры (Podman, Docker в rootless-режиме), часть CI-песочниц и механизмы изоляции браузеров вроде Chrome и Firefox. Перед раскаткой стоит прогнать тесты.
Если эксплойт уже отработал, команда echo 3 > /proc/sys/vm/drop_caches сбрасывает отравленный кэш, но не закрывает уже полученный root-shell и не лечит ядро. Файловые системы целостности (FIM) бесполезны для обнаружения: диск чистый, агенты смотрят не туда, куда нужно. Любой инцидент требует полной ротации учётных данных и нормального форензик-обследования, а не «сбрасывания кэша и перезапуска».
Хронология и исторический контекст
Кривая истории раскрытия здесь такая. Ещё в конце мая исправление ушло в рассылку netdev, причём оформлено как «обычный патч против повреждения данных», без CVE, без security-тега и без упоминания безопасности. Детали, достаточные для эксплуатации, провисели публично несколько недель. 16 июня патч приняли в апстрим и присвоили CVE-2026-46331, а 17 июня появился PoC. К 25 июня Red Hat подтвердил уязвимость RHEL 8/9/10, Debian закрыл Trixie, а Ubuntu продолжал держать в списке все релизы.
CVE-2026-46331 вписывается в целое семейство похожих багов, связанных с порчей page-cache через «быстрые пути» ядра: Dirty Pipe (CVE-2022-0847), Copy Fail, DirtyClone (CVE-2022-25212), Dirty Frag. «pedit COW» отличается точкой входа — комбинация act_pedit и пользовательских неймспейсов с CAP_NET_ADMIN внутри namespace. Принципиальная мысль, которую подчёркивают исследователи: для таких дыр полагаться на сканеры и обновление правил слишком медленно — эксплойт появляется за сутки, и окно для атаки открывается задолго до того, как вендор разошлёт бюллетени.
Из всего этого вытекает простой практический вывод: на машинах, где есть хоть один лишний локальный пользователь, патч tcf_pedit_act() и перезагрузка должны случиться как можно скорее, а запрет act_pedit или пользовательских неймспейсов — первая линия обороны до того, как патч можно поставить.