Уязвимости в Linux, о которых рассказали исследователи в 2026 году, бьют по одной и той же точке: ядро меняет страницу файла в оперативной памяти, хотя сам файл открыт только для чтения. На диске всё выглядит нормально, но в page cache уже лежит изменённая версия. Именно так устроены Copy Fail, Dirty Frag и pedit COW.

Эти ошибки не дают «root» сами по себе. Зато они открывают путь к повышению привилегий: атакующий меняет содержимое кешированной страницы, а затем система исполняет уже подправленный код. Для защитников это неприятный пример того, как одна ошибка в ядре ломает базовую логику прав доступа.

История инцидента

В центре сюжета — связка из page cache, zero-copy и подсистем ядра, которые любят работать с одной и той же памятью без лишнего копирования. Если процесс читает файл, ядро может отдать не отдельный буфер, а ссылку на уже существующую страницу. Это быстрее, но требует очень аккуратной проверки: можно ли менять эту страницу, или её надо сначала отделить от общего кеша.

Именно здесь и возникают проблемы. В одном случае криптографическая подсистема пишет служебные данные прямо в исходный буфер. В другом — сетевой стек расшифровывает пакет «на месте» и меняет общую страницу как собственную. В третьем — ядро неверно рассчитывает границы Copy-on-Write и оставляет часть памяти общей.

Публичные proof of concept показали один и тот же итоговый эффект: файл на диске не трогают, но кешированная копия уже отличается от оригинала. Это особенно опасно для setuid-программ и системных бинарников. В статье о критической RCE-уязвимости GitLab мы уже разбирали похожую логику: когда уязвимость затрагивает доверенный компонент, последствия быстро выходят за рамки одного процесса.

Что пошло не так в защите

Первая ошибка — доверие к общей памяти. Открыть файл только для чтения ещё не значит, что ядро не сможет записать туда что-то через другой механизм. Если страница попала в обработку через AF_ALG, XFRM или сетевой буфер, проверка прав на уровне файловой системы уже не спасает.

Вторая ошибка — неверная работа с in-place-операциями. Подсистема считает, что имеет дело с собственной памятью, хотя на самом деле это общая страница из кеша. Так работает Copy Fail: модуль authencesn использует выходной буфер как рабочую область и меняет содержимое кешированной страницы. В похожей логике уязвимость Dirty Frag позволяет ядру расшифровать данные прямо в общей памяти.

Третья ошибка — неправильная граница защиты. В pedit COW ядро пытается подготовить Copy-on-Write, но считает размер безопасной области заранее и ошибается. В итоге запись выходит за рамки того, что должно было стать частной копией. В разборе атаки на старые iPhone и iPad мы уже видели похожий принцип: если базовый механизм защиты даёт сбой, дальше ломается вся цепочка доверия.

Уроки для читателя

Главный вывод простой: права доступа к файлу и безопасность ядра — не одно и то же. Если уязвимость живёт в обработке общей памяти, обычная файловая политика уже не помогает. Нужен патч ядра, а не только «аккуратные права» на уровне пользователя.

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

Ещё один вывод касается изоляции. User namespaces помогают ограничить влияние процесса внутри его среды, но не защищают от ошибок, если общий page cache остаётся разделяемым. Это не повод отказываться от изоляции, но хороший аргумент не считать её универсальной бронёй.

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

Практические выводы и чек-лист

Если у вас Linux-сервер, рабочая станция или контейнерная среда, проверьте не абстрактную «безопасность», а конкретные опоры. Ниже — короткий список того, что можно сделать уже сейчас.

  • Проверьте версию ядра и сверьте её с бюллетенями безопасности своего дистрибутива.
  • Установите все доступные обновления ядра, а затем перезагрузите систему, чтобы загрузить исправленную версию.
  • Ограничьте запуск setuid-программ там, где это возможно по бизнес-процессу.
  • Пересмотрите использование пользовательских пространств имён и сервисов, которым они действительно нужны.
  • Проверьте, не используются ли на сервере криптографические и сетевые подсистемы, которые попадают в зону риска из-за in-place-обработки.
  • Для рабочих устройств включите менеджер паролей и 2FA, а также обновите политику доступа к корпоративным аккаунтам.
  • Если система критична, запланируйте отдельное окно на тестирование обновления ядра, а не ставьте его «когда-нибудь потом».

Такой подход не требует специальных инструментов и помогает не пропустить то, что чаще всего игнорируют: ядро может менять данные не там, где вы этого ждёте. Именно в этом и состоит опасность Copy Fail, Dirty Frag и pedit COW — файл выглядит защищённым, пока его страница уже переписана в памяти.

Поделиться: