OVSwrap под номером CVE-2026-64531 позволяет обычному локальному пользователю получить права root на заметной части Linux-дистрибутивов с настройками по умолчанию. CNA оценивает уязвимость в 7,8 балла по CVSS 3.1, а публичный PoC уже опубликован и содержит готовые профили примерно для 800 точных сборок ядра x86-64.
Если у вас есть общие серверы, сборочные хосты CI, учебные стенды или хосты администрирования, проверять стоит не только версию ядра, но и наличие модуля openvswitch, а также политику непривилегированных пространств имен пользователей.
Ошибка живет в модуле Open vSwitch внутри ядра
Исследователь Asim Manizada раскрыл уязвимость 28 июля 2026 года, после сообщения в security@kernel.org и сопровождающим OVS 19 июня 2026 года. Проблема находится не в демоне ovs-vswitchd, а в ядровом модуле обработки трафика Open vSwitch. Поэтому для атаки не нужен ни поднятый OVS bridge, ни запущенный демон, ни CAP_NET_ADMIN в хостовой системе.
На уязвимых машинах достаточно, чтобы модуль Open vSwitch был доступен, а непривилегированные пространства имен пользователей (user namespaces) были включены. Даже если openvswitch еще не загружен, его может подтянуть сама система через Generic Netlink, так что пустой lsmod здесь успокаивает ровно до первого обращения к уязвимому пути.
Старый баг стал опасным после снятия лимита
Технически проблема упирается в поле длины Netlink-атрибута nla_len: оно 16-битное и вмещает максимум 65 535 байт. Ошибка в Open vSwitch жила около 13 лет, но долго не была пригодна для практической эксплуатации из-за внутреннего лимита в 32 КиБ на сгенерированный поток действий. В марте 2025 года upstream убрал этот предел коммитом a1e64addf3ff, потому что он ломал реальные нагрузки, в том числе в крупных развертываниях OpenStack.
После этого атакующий может набить действие CLONE сотнями вложенных conntrack-поддействий. На x86-64 каждое из них разворачивается примерно до 164 байт, длина переполняется, и парсер продолжает разбор уже внутри контролируемых данных. Отсюда PoC строит утечку адресов ядра, произвольное чтение и точечное уменьшение значения по нужному адресу, а затем сводит fsuid и fsgid целевого процесса к нулю.
Публичный PoC уже лежит в GitHub. Он помечен как разрушительный, требует поддержки OVS conntrack, FTP conntrack helper и установленного sudo, а после успеха правит /etc/sudoers.d или /etc/sudoers и открывает оболочку root. Это уже не академический разбор, а практический инструмент для проверки, открыт ли хост этой уязвимости.
Какие ветки уже исправлены
Исправление попало в stable-ветки 24 июля 2026 года. Первые безопасные upstream-релизы: Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 и 7.1.5. По данным технического разбора исследователя и карточки NVD, затронуты ветки 5.15.180-5.15.211, 6.1.132-6.1.177, 6.6.84-6.6.144, 6.12.20-6.12.96, 6.18.0-6.18.39 и 7.1.0-7.1.4; серии 6.13.8-6.13.12, 6.14-6.17, 6.19 и 7.0 upstream уже не поддерживает, поэтому отдельных stable-патчей для них не будет.
Но смотреть только на upstream-номер нельзя: дистрибутивы часто закрывают такие дыры обратным портированием исправлений. В неполной тестовой матрице эксплойт сработал на AlmaLinux 9/10, Debian 12/13, Fedora 42-44, Rocky Linux 9/10, Ubuntu 22.04 и ряде других систем. На Ubuntu 24.04 прямой путь блокировал AppArmor, но вариант через aa-exec возвращал достижимость уязвимого кода; штатная Ubuntu 26.04 этот маршрут для обычного пользователя уже перекрывает, если не отключать ограничение AppArmor вручную.
Значение для рынка
Для российских и СНГ-команд история неприятна своей приземленностью. Open vSwitch часто встречается в виртуализации, облачных платформах и OpenStack-инфраструктуре, а базы вроде Ubuntu, Debian, Rocky и AlmaLinux стоят под сборочными системами, общими серверами и внутренними сервисами. Один уже скомпрометированный аккаунт в такой среде может быстро превратить локальную уязвимость в проблему всего хоста.
Если Open vSwitch на машине не нужен, самый быстрый временный шаг - запретить загрузку модуля правилом install openvswitch /bin/false в /etc/modprobe.d/ovswrap.conf и убрать уже загруженный модуль перезагрузкой или выгрузкой. Если нужен, ставить стоит именно исправленное ядро от поставщика дистрибутива и отдельно пересматривать политику пространств имен пользователей: их отключение закрывает путь для обычного локального пользователя, но не спасает от процесса или контейнера, который уже получил CAP_NET_ADMIN в своем сетевом пространстве имен.
Дальше все зависит от скорости патчей: публичный PoC уже вышел, и времени на спокойную раскачку у инфраструктурных команд почти не осталось.
Источники: технический разбор Asim Manizada на , публикация и карточка .