В ядре Linux нашли новую уязвимость повышения привилегий. Исследователи JFrog назвали её DirtyClone. В базе CVE она проходит как CVE-2026-43503. Это локальная уязвимость: атакующему уже нужен доступ к системе, контейнеру или пользовательской сессии. Но после этого он может получить root за счёт манипуляции page cache — кэшем файловых страниц в памяти ядра.
JFrog описывает DirtyClone как вариант DirtyFrag — семейства ошибок в сетевом стеке Linux. Эти баги связаны с тем, как ядро обрабатывает socket buffers, или skb: внутренние структуры, через которые проходят сетевые пакеты. При определённых условиях skb может ссылаться на память, связанную с файлом в page cache. Если затем сетевой подсистеме разрешить изменять этот буфер «на месте», ядро может неожиданно изменить данные, которые логически относятся к файлу.
В атаке это превращается в неприятный трюк: файл на диске остаётся прежним, а его копия в памяти меняется. Если в page cache лежит, например, привилегированный бинарник, при следующем запуске система может выполнить уже изменённый вариант из памяти. Итог — обход проверки и повышение прав.
Название DirtyClone сразу отсылает к Dirty Pipe — громкой уязвимости Linux 2022 года. Там тоже использовалась идея повреждения page cache: атакующий мог менять данные, связанные с файлами, без нормальной записи на диск. DirtyClone не является прямой копией Dirty Pipe, но находится в той же неприятной категории: ядро путает границы между «данные файла» и «данные буфера», а атакующий превращает это в запись туда, куда писать нельзя.
DirtyFrag, Fragnesia и DirtyClone показывают один общий паттерн. В современных оптимизациях ядро старается не копировать данные лишний раз: zero-copy, splice, сетевые буферы, криптографические преобразования, IPsec. Это даёт производительность. Но если где-то теряется метка «эта память общая, её нельзя менять напрямую», оптимизация становится уязвимостью.
DirtyClone как раз про потерянную метку. В отдельных helper-функциях ядра флаг SKBFL_SHARED_FRAG не передавался дальше при переносе фрагментов. Этот флаг нужен, чтобы ядро понимало: skb ссылается на разделяемую память, связанную с page cache. Если флаг потерян, последующие подсистемы могут считать буфер обычным сетевым пакетом и изменить его напрямую.
На высоком уровне схема такая: атакующий добивается, чтобы сетевой буфер ссылался на страницу памяти, связанную с важным исполняемым файлом. Затем он заставляет сетевой стек пройти через путь, где буфер клонируется, а защитная метка теряется. После этого IPsec-обработка выполняет преобразование данных «на месте» и меняет page cache.
Файл на диске при этом не меняется. Мониторинг целостности файлов может ничего не увидеть, потому что байты на накопителе остались прежними. Меняется только то, что уже лежит в памяти. JFrog отдельно подчёркивает, что атака может быть тихой: без очевидных kernel logs или audit-следов.
Это делает DirtyClone особенно неприятной для серверов. Администратор может проверить бинарник на диске, увидеть нормальный хеш и решить, что всё чисто. Но в памяти на момент эксплуатации уже могла быть другая версия страницы.
Уязвимость затрагивает Linux-системы, где нет полного набора исправлений для семейства DirtyFrag. JFrog пишет, что полностью незащищённые системы с CVE-2026-43284 и CVE-2026-43500 остаются широко уязвимыми, а системы, где поставили только первые mitigation-патчи без последующих исправлений CVE-2026-46300 и CVE-2026-43503, всё ещё могут быть атакованы через обходы.
Особенно важны дистрибутивы и окружения, где включены unprivileged user namespaces. JFrog указывает Debian, Ubuntu и Fedora как популярные системы, где эксплуатация подтверждена или релевантна при нужных настройках. Ubuntu описывает связанную проблему как logic flaw в XFRM ESP-in-TCP subsystem при обработке socket buffer fragments, а Debian ведёт отдельную карточку CVE-2026-43503 в security tracker.
Главная зона риска — multi-tenant-инфраструктура: облачные серверы, контейнерные хосты, Kubernetes-кластеры, CI/CD-раннеры, shared hosting, dev-платформы и любые среды, где недоверенный пользовательский код работает рядом с общим ядром.
JFrog сообщила о проблеме мейнтейнерам ядра 19 мая 2026 года. Патч был merged в mainline 21 мая, CVE опубликован 23 мая, а Linux v7.1-rc5 от 24 мая стал первым фиксированным тегом. SecurityWeek также указывает, что уязвимость закрыли вскоре после сообщения разработчикам ядра.
Но для администраторов важен не номер mainline-ядра, а конкретное ядро их дистрибутива. Debian, Ubuntu, Fedora, RHEL-подобные системы и облачные провайдеры обычно backport-ят исправления в свои ветки. Поэтому проверять надо не только uname -r, а advisories своего поставщика и наличие патча именно для CVE-2026-43503 и соседних DirtyFrag-фиксов.
JFrog подчёркивает: система считается защищённой только после применения всей цепочки исправлений. Частичный патч может закрыть один путь, но оставить другой.
Что делать администраторам:
Обновить ядро через официальный канал дистрибутива или облачного провайдера. Для DirtyClone опасна именно ситуация «поставили часть патчей и успокоились». Нужно убедиться, что закрыты CVE-2026-43503 и связанные исправления DirtyFrag/Fragnesia.
Проверить unprivileged user namespaces. Если они не нужны, их стоит отключить. JFrog указывает kernel.unprivileged_userns_clone=0 как один из workaround-вариантов, когда немедленный патч невозможен. Для некоторых рабочих нагрузок это может сломать rootless-контейнеры или developer-tooling, поэтому изменение лучше тестировать, но для серверов с недоверенным кодом это сильная мера снижения риска.
Убрать лишний CAP_NET_ADMIN. Контейнерам и сервисам нельзя выдавать эту capability «на всякий случай». Если приложение просит сетевые права, нужно понимать, зачем именно. В Kubernetes стоит пересмотреть securityContext, Pod Security Standards, admission policies и настройки privileged-контейнеров.
Временно ограничить опасные модули, если патч поставить нельзя. JFrog упоминает blacklisting esp4, esp6 и rxrpc как workaround для блокировки in-place decryption primitives. Это может повлиять на IPsec/RxRPC-сценарии, поэтому мера подходит не всем, но для части серверов она лучше, чем открытый путь к root.
Считать локальный доступ серьёзным риском. DirtyClone не даёт удалённый вход с нуля, но в реальной инфраструктуре локальный код появляется постоянно: CI-джобы, контейнеры, плагины, user workloads, shared runners, sandbox-задачи, временные аккаунты. Если такой код может превратиться в root на хосте, это уже критичный инцидент.
С обнаружением всё сложно. JFrog пишет, что эксплуатация может не оставлять kernel logs или audit-следов. Обычный контроль целостности файлов тоже может промолчать, потому что диск не меняется.
Поэтому детект должен смотреть на поведение вокруг атаки: неожиданные namespace-операции, получение CAP_NET_ADMIN, странные IPsec/XFRM-настройки, необычные netfilter-правила, запуск привилегированных бинарников после сетевых манипуляций, подозрительную активность внутри контейнеров и процессы, которые пытаются работать с системными бинарниками через нестандартные пути.
Для Kubernetes полезно отдельно смотреть на поды с privileged: true, добавлением NET_ADMIN, hostNetwork, необычными initContainers и workload-ами, которые внезапно начинают управлять сетевыми правилами.
Полностью надёжного «алерта DirtyClone» может не быть. Поэтому главная защита — патч и снижение доступных primitives, а не ожидание идеального детекта.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
