Уязвимость Open vSwitch под идентификатором CVE-2026-64531 позволяет обычному локальному пользователю подняться до root на заметной части Linux-дистрибутивов с настройками по умолчанию. Ситуацию делает особенно неприятной публичный PoC: в нем уже есть готовые записи примерно для 800 сборок ядра x86-64. Для команд, которые держат shared-хосты, CI-машины и серверы с несколькими арендаторами, это не теоретика, а повод срочно сверить версии ядра и политику namespaces.
Как пишет The Hacker News, уязвимость Open vSwitch получила кодовое имя OVSwrap, номер CVE-2026-64531 и оценку 7.8 по CVSS; ее раскрыл исследователь Asim Manizada 28 июля 2026 года, после того как 19 июня сообщил о проблеме в security@kernel.org и сопровождающим OVS. Баг живет не в userspace-демоне ovs-vswitchd, а в datapath ядра Linux. Это важная деталь: для атаки не нужен ни заранее поднятый OVS bridge, ни запущенный демон, ни host-level CAP_NET_ADMIN. Достаточно, чтобы в системе был доступен kernel-модуль Open vSwitch и были разрешены непривилегированные user namespaces. Если модуль установлен, но еще не загружен, его может подтянуть сама система через Generic Netlink, так что пустой вывод lsmod здесь успокаивает ровно до первого расследования.
Корень проблемы старше многих текущих LTS-веток. В Open vSwitch действия потока сериализуются как Netlink-атрибуты, а поле длины nla_len у них 16-битное: максимум 65 535 байт на вложенный атрибут. Ошибочное присваивание жило в коде около 13 лет, но долго было прикрыто потолком в 32 КиБ на весь сгенерированный поток действий. В марте 2025 года этот лимит убрали, потому что он давал непредсказуемые сбои, в том числе в крупных развертываниях OpenStack. После этого старый баг перестал сидеть тихо. Атакующий набивает CLONE-сценарий сотнями conntrack-поддействий; на x86-64 ядро разворачивает каждое примерно до 164 байт, длина переполняется, парсер возвращается внутрь контролируемых данных и начинает исполнять подложенные OVS-действия.
С инженерной точки зрения это особенно неприятный класс ошибки: памяти ломается много, а хаоса мало. Исследователь описывает надежность как почти логическую, потому что точка, куда возвращается разборщик, предсказуемо попадает в тот же непрерывный буфер и не требует долгих упражнений с heap grooming. Из этого переполнения собираются три примитива: утечка указателя ядра через поддельное OUTPUT-действие, произвольное чтение ядра через подставной tunnel SET и адресный decrement при разборе ложного tun_dst. Дальше PoC находит credentials нужного процесса и на современных ядрах сводит fsuid и fsgid к нулю. В переводе на человеческий: обычный пользователь превращается в root без драматических танцев с гонками и миллионом попыток.
Исправление уже ушло в stable-ветки 24 июля. Первыми безопасными upstream-релизами названы Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 и 7.1.5; ветви 6.13-6.17, 6.19 и 7.0 upstream уже не поддерживаются и патчей не получат. Но здесь есть стандартная для ядра ловушка: смотреть только на upstream-номер нельзя, потому что дистрибутивы живут на backport'ах и своих патчах. Проверять, закрыта ли уязвимость Open vSwitch в конкретной поставке, лучше по vendor advisory. По неполному, но довольно широкому тестовому списку эксплойт на дефолтных конфигурациях сработал на AlmaLinux 9 и 10, Alpine 3.22-3.24, Amazon Linux 2023, Arch, CentOS Stream 9 и 10, Debian 12 и 13, Fedora 42-44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 и 10, Ubuntu 22.04. На Ubuntu 24.04 прямой путь резал AppArmor, но обход через aa-exec восстанавливал достижимость уязвимого кода; штатная Ubuntu 26.04 этот маршрут для обычного пользователя уже блокировала.
Для админов и платформенных команд неприятность не только в самом root-доступе, но и в том, где он появляется. OVSwrap особенно опасен на хостах, которые делят несколько пользователей или недоверенные workloads: shared-серверы, сборочные машины, учебные стенды, внутренние jump-хосты. CloudLinux в своем advisory формулирует риск без лишней драмы: достаточно одного уже скомпрометированного аккаунта, чтобы локальная проблема превратилась в проблему всего сервера. Публичный PoC к тому же не академический. Он помечен как разрушительный, требует поддержки OVS conntrack, FTP conntrack helper и установленного sudo, после успеха правит /etc/sudoers.d или /etc/sudoers, открывает root-shell и оставляет процессы и состояние OVS висеть, чтобы не разбирать опасно сломанную конструкцию. В репозитории лежат готовые записи примерно для 800 точных x86-64 сборок ядра, а для остальных есть попытка динамически вывести нужные параметры по символам или BTF.
Практический план действий короткий. Если vendor уже выпустил исправленное ядро, ставить нужно именно его, а не гадать по номеру ветки. Если Open vSwitch на хосте не нужен, временный компромисс простой: запретить будущую загрузку модуля правилом install openvswitch /bin/false в /etc/modprobe.d/ovswrap.conf, а уже загруженный модуль выгрузить или убрать перезагрузкой. Отключение непривилегированных user namespaces закрывает маршрут для обычного локального пользователя, но не защищает от процесса или контейнера, который уже получил CAP_NET_ADMIN в атакуемом сетевом namespace. Исследователь отдельно оговаривает: контейнерный сценарий он считает теоретически достижимым, но в опубликованном PoC не показал. Для сред, где нужно оставить и OVS, и namespaces, в наборе есть аварийный BPF-guard, но это уже режим пожарной команды, а не нормальная эксплуатация. Для ориентира: Amazon Linux 2, Debian 11, Rocky Linux 8 и Ubuntu 20.04 по протестированному пути не эксплуатировались, потому что там остались более старые кодовые ветки.
История OVSwrap неприятна именно своей будничностью: баг прожил 13 лет, а наружу вышел после попытки починить надежность и убрать мешающий лимит для реальных нагрузок. Для Linux-экосистемы это очередное напоминание, что локальная уязвимость в сетевом datapath давно перестала быть локальной мелочью, если на одном хосте живут разные люди, сервисы и контейнеры. Технический разбор, детали PoC и список затронутых сборок собраны в материале .