Специалисты компании Tencent выявили опасную уязвимость use-after-free в сетевом стеке ядра Linux. Дефект находился в коде начиная с 2008 года. Этой уязвимости присвоено название SCTPhantom, и она дает возможность локальному злоумышленнику получить права root-пользователя. Во время исследования удалось также продемонстрировать использование этого дефекта для выхода за пределы контейнера.
Уязвимость зарегистрирована под номером CVE-2026-64564. Проблема связана с реализацией протокола SCTP (Stream Control Transmission Protocol), поддерживающего multihoming – возможность соединения использовать несколько адресов и каналов связи между компьютерами в сети. Уязвимость затрагивает механизм динамического изменения адресов в SCTP, позволяющий изменять список адресов во время активного соединения.
Специалисты Tencent установили уровень опасности CVE-2026-64564 равным 8,5 по шкале CVSS. Национальная база уязвимостей (NVD) пока не опубликовала собственную оценку серьезности.
Исследование показало, что проблема возникает при обработке SCTP-сообщений ASCONF. Ядро использует различные адреса для валидации и выбора пути в сети. Операция удаления адреса (DEL-IP) проверяется по IP адресу отправителя пакета, однако выбор маршрута основан на адресе, содержащемся в самом сообщении ASCONF.
Злоумышленник может отправить специально сформированное сообщение последовательностью [Address L] [DEL-IP L] [DEL-IP 0.0.0.0]. Ядро сначала удаляет маршрут, связанный с адресом L, а потом подстановочная операция повторно обращается к уже удаленному объекту. В результате соединение SCTP продолжает использовать уже освобожденную область памяти, возникает ошибка типа use-after-free.
SCTPhantom присутствует в Linux начиная с версии 2.6.25 (2008 года). Однако риск уменьшается требованием локального доступа и наличием поддержки SCTP на целевой системе. Тем не менее исследователи подтвердили получение прав администратора на Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 и OpenCloudOS.
Исследовательская группа также продемонстрировала применение CVE-2026-64564 для выхода из контейнера. На первом этапе разработанный эксплоит требовал активации параметров net.sctp.addip_enable и net.sctp.addip_noauth_enable, что предполагало наличие полномочий CAP_NET_ADMIN. Позднее команда нашла метод активировать требуемые возможности SCTP через отдельный сокет, минуя изменение системных параметров. В финальных экспериментах контейнер работал со стандартным профилем seccomp без привилегий CAP_NET_ADMIN и CAP_SYS_ADMIN, и в шести из восьми попыток атаки удалось получить права администратора на хост-системе.
Исследователи не раскрыли информацию о конкретном использованном контейнерном движке. Авторы указывают, что возможность эксплуатации напрямую зависит от разрешения доступа к SCTP-сокетам внутри контейнера, а также от параметров seccomp и настроек изоляции пространств имен.
Исправление включено в выпуски ядра 7.1.6, 6.18.42, 6.12.101 и 6.6.148, опубликованные 3 августа 2026 года.
