27 октября 2026 года CloudLinux сообщила о расширении доступности исправлений для ZDI-CAN-33367 — опасной уязвимости сетевого стека Linux, позволяющей локальному пользователю получить права root. Livepatch-исправления стали доступны для систем семейства Enterprise Linux 9 и 10, однако часть дистрибутивов всё ещё ожидает полноценного обновления ядра. Публичный эксплойт уже существует, поэтому особое внимание привлекли серверы с несколькими пользовательскими учётными записями.
ZDI-CAN-33367 позволяет изменять защищённые файлы через память ядра Linux
Уязвимость ZDI-CAN-33367 затрагивает обработку сетевых данных в ядре Linux. Она позволяет обычному пользователю изменять содержимое файлов, к которым у него есть доступ только на чтение. В определённых условиях такая операция приводит к повышению привилегий до root — учётной записи с полным административным доступом к системе.
О проблеме стало известно 21 октября, когда специалисты Trend Micro Zero Day Initiative (ZDI) направили отчёты разработчикам ядра Linux. Технические сведения вместе с работающим демонстрационным эксплойтом оказались в публичных списках рассылки.
Уязвимость получила оценку 7,8 балла по шкале CVSS, что соответствует высокому уровню опасности. По состоянию на 28 октября отдельный идентификатор CVE ей ещё не присвоен.
Особенность ZDI-CAN-33367 связана с механизмом page cache — областью оперативной памяти, где Linux временно хранит содержимое файлов для ускорения чтения.
Допустим, файл принадлежит администратору, а обычный пользователь может только просматривать его. В нормальных условиях система запрещает изменять такой файл. Уязвимость позволяет обойти это ограничение и подменить данные в кэше ядра.
Изменения при этом первоначально остаются в оперативной памяти. Сам файл на диске сохраняет прежнее содержимое, но процессы, читающие его через изменённые страницы кэша, могут получить подставленные данные. Именно этот механизм позволяет построить атаку с повышением привилегий.
Ошибка в skb_zerocopy() нарушает защиту общих страниц памяти
Причина проблемы находится в функции skb_zerocopy(), которую сетевой стек использует для передачи данных между буферами без лишнего копирования. При такой передаче ядро должно сохранять специальный признак SKBFL_SHARED_FRAG: он показывает, что страницы памяти используются совместно с другим объектом, например с кэшем файла.
В уязвимом варианте skb_zerocopy() передаёт ссылки на страницы, но теряет защитный признак. Затем механизм IPsec ESP может изменить содержимое этих страниц при расшифровке сетевых данных, полагая, что работает с доступным для записи буфером. В результате изменяется кэш файла, на который у пользователя нет прав записи.
Разработчики подготовили исправление, сохраняющее SKBFL_SHARED_FRAG при передаче буфера. 27 октября CloudLinux сообщила, что патч принят в дерево разработки сетевой подсистемы Linux, но ещё не вошёл в основную ветку ядра.
Механизм напоминает ранее раскрытые Dirty Frag и Fragnesia. У этих уязвимостей схожий результат — изменение данных в page cache с обходом обычных файловых разрешений. Однако ZDI-CAN-33367 использует отдельный путь через skb_zerocopy(). Исправление Dirty Frag (CVE-2026-43284) само по себе её не закрывает.
Локальный доступ и пространства имён определяют условия атаки
Для использования опубликованного эксплойта требуется возможность выполнять код на уязвимой машине. Одного сетевого подключения к серверу без доступа к выполнению команд недостаточно. Злоумышленник может начать атаку из обычной пользовательской учётной записи либо после компрометации размещённого на сервере приложения.
Особенно чувствителен к такому сценарию виртуальный хостинг: несколько клиентов используют одно ядро Linux. Получив доступ к одной непривилегированной учётной записи, атакующий потенциально может повысить полномочия до root и выйти за пределы своего аккаунта.
Опубликованная цепочка использует пользовательские пространства имён (user namespaces). Они позволяют обычному пользователю создавать изолированную среду с собственными сетевыми настройками. Если непривилегированное создание таких пространств запрещено, описанный путь атаки становится недоступным для обычной учётной записи. Это ограничение само по себе не заменяет исправления ядра, в том числе для процессов с уже имеющимися повышенными полномочиями.
Команда CloudLinux воспроизвела получение root на AlmaLinux 8, 9 и 10, Debian 12 и 13, Ubuntu 24.04 и 26.04, а также на CloudLinux 9 и 10. Для отдельных редакций CloudLinux фактическая доступность атаки зависит от настроек сервера. Проверка только номера дистрибутива поэтому не даёт полного ответа.
27 октября CloudLinux уточнила доступность патчей для EL9 и EL10
Согласно официальному журналу инцидента CloudLinux, к 27 октября появились новые каналы доставки исправлений. Для систем семейства Enterprise Linux 9 livepatch находился в производственном канале KernelCare с 26 октября. Для Enterprise Linux 10 расширилась доступность исправлений через ePortal, в том числе для AlmaLinux 10 и CloudLinux 10 с 27 октября.
| Система или семейство | Подтверждённое состояние на 27 октября |
| AlmaLinux 9 и CloudLinux 9 | Livepatch KernelCare доступен в производственном канале; ядро AlmaLinux 5.14.0-687.60.1.el9_8 содержит исправление |
| RHEL 9, Oracle Linux 9, Rocky Linux 9 | Livepatch доступен в производственном канале KernelCare, но ещё отсутствует в ePortal |
| RHEL 10, Oracle Linux 10, Rocky Linux 10 | Livepatch добавлен в ePortal с 26 октября |
| AlmaLinux 10 и CloudLinux 10 | Livepatch доступен в ePortal с 27 октября; исправленное ядро AlmaLinux 10 в производственном канале на момент сообщения не подтверждено |
| Семейство Enterprise Linux 8 | Livepatch подготовлен к выпуску, но ещё не опубликован |
| CloudLinux 7 hybrid и CloudLinux 8 | Исправленные ядра 4.18.0-553.177.1.lve.1 доступны в бета-канале |
| Debian и Ubuntu | Работа над livepatch через KernelCare продолжается, дата выпуска не названа |
Статус зависит от способа доставки: наличие исправленного ядра в тестовом репозитории, публикация livepatch в производственном канале и доступность через ePortal — разные этапы. Ещё 23 октября AlmaLinux представила тестовые сборки для версий 8, 9 и 10. Поэтому наличие такого пакета в репозитории само по себе не подтверждает, что исправление уже установлено на конкретном сервере.
Проверка user namespaces и временное снижение риска
CloudLinux описывает простой способ проверить одно из необходимых условий опубликованной атаки:
sysctl user.max_user_namespacesЗначение 0 означает, что обычные пользователи не могут создавать новые пользовательские пространства имён через этот механизм. Положительное значение допускает их создание, поэтому на затронутом ядре остаётся возможность пройти начальный этап известного эксплойта.
В качестве временного ограничения CloudLinux указывает параметр user.max_user_namespaces = 0, который можно установить через конфигурацию sysctl. Изменение вступает в силу без перезагрузки. У него есть побочные эффекты: могут перестать работать rootless-контейнеры Podman и Docker, непривилегированные LXC, отдельные песочницы браузеров и приложения, использующие пространства имён для изоляции.
Для систем с KernelCare разработчик приводит команды проверки установленного livepatch:
kcarectl --patch-info | grep -i 33367После установки нового пакета ядра его фактически загруженную версию можно узнать через uname -r. Для обычного обновления ядра требуется перезагрузка, тогда как livepatch изменяет работающий код без неё. На серверах, где нельзя отключить user namespaces из-за контейнерных задач, различие между этими способами исправления особенно существенно.
Полное устранение ZDI-CAN-33367 пока зависит от дистрибутива
К 28 октября защитные исправления уже доступны для ряда серверных систем, но их распространение остаётся неоднородным. Часть поставщиков выпустила ядра в тестовые или бета-репозитории, часть предлагает livepatch, а для Debian и Ubuntu в канале KernelCare работа ещё продолжается.
Разработчики также подтвердили существование публичного эксплойта, который получает root на нескольких распространённых дистрибутивах Linux. При этом CloudLinux не сообщала о подтверждённых случаях эксплуатации ZDI-CAN-33367 в реальных атаках.
Дальнейшая картина зависит от включения исправления в основную ветку Linux и публикации стабильных пакетов каждым поставщиком. Пока единого номера версии ядра, который одинаково отражал бы устранение проблемы во всех дистрибутивах, нет.
