Закрываем уязвимость SCTPhantom — повышение привилегий и выход из контейнера в ядре Linux

SCTPhantom — уязвимость обращения к освобожденной памяти (use-after-free) в подсистеме SCTP ядра Linux, позволяющая локальному непривилегированному процессу получить права суперпользователя (root) на узле. В контейнере с минимальными привилегиями и штатным профилем seccomp, по данным исследователей, возможен выход из контейнера на узел. Вектор доступен только при загруженном модуле sctp. Kubernetes^® и сетевые плагины SCTP не используют, поэтому блокировка модуля закрывает вектор без потерь для большинства кластеров.

Исследователи Tencent продемонстрировали рабочий эксплойт, поэтому обновление следует считать срочным. Базовые меры: для Yandex Managed Service for Kubernetes^® применить защитный DaemonSet (основная мера — ревизия образа узла с исправлением ещё не выпущена). Для Yandex Compute Cloud временно заблокировать модуль и обновить ядро, ограничить размещение недоверенных нагрузок, контролировать конфигурации и обновления.

Описание

Уязвимость существует в обработке сообщений протокола SCTP ASCONF (Dynamic Address Reconfiguration, RFC 5061). Ошибка возникает из-за расхождения между адресом, который проверяется при удалении пути, и адресом, который используется для последующей обработки. Это позволяет удалить путь и затем обратиться к уже освобождённой памяти. При наличии локального непривилегированного доступа и загруженного модуля sctp обращение к освобожденной памяти приводит к повышению привилегий до суперпользователя.

По данным Tencent Zhuque Lab (исследователей, обнаруживших уязвимость), в контейнерной среде эксплуатация возможна без предоставления контейнеру CAP_NET_ADMIN и CAP_SYS_ADMIN при активном штатном профиле seccomp: ранние версии эксплойта требовали включённых sysctl net.sctp.addip_enable и net.sctp.addip_noauth_enable, но затем был найден путь, включающий нужные возможности на уровне отдельного сокета и не затрагивающий эти sysctl.

Выход из контейнера — заявление Tencent на основе собственного тестирования, независимо результат пока не воспроизведён. На отдельной виртуальной машине выход из контейнера неприменим — угроза сводится к локальному повышению привилегий до root.

Публичной эксплуатации уязвимости в реальных атаках на момент публикации не зафиксировано. Исследователи Tencent продемонстрировали рабочий эксплойт на нескольких дистрибутивах. Вендоры дистрибутивов выпускают бэкпорты исправления, сохраняя прежнюю версию в строке, поэтому версия ядра сама по себе не является признаком уязвимости — необходимо сверяться с бюллетенем вендора.

Уязвимые продукты и версии

Уязвимы все версии ядра Linux начиная с 2.6.25 (2008 год) до версии с исправлением.

Безопасная версия уязвимого продукта или патч

Уязвимость устранена в версиях:

• 6.6.148 (стабильная ветка 6.6.y)
• 6.12.101 (стабильная ветка 6.12.y)
• 6.18.42 (стабильная ветка 6.18.y)
• 7.1.6 (стабильная ветка 7.1.y)
• 7.2-rc5 (mainline).

Уровень опасности по CVSS

• CVSS 4.0: 8.5 (High) — оценка Tencent Zhuque Lab.
• CVSS 3.1: 9.8 (Critical) — оценка CNA kernel.org, вектор AV:N. Сетевой вектор в этой оценке спорен: эксплуатация требует локального доступа.

Собственной оценки и классификации слабости (CWE) NVD на момент публикации не предоставил.

Рекомендации по обнаружению уязвимости

Проверка состоит из двух частей: загружен ли модуль сейчас и заблокирована ли его автозагрузка. Чистого вывода lsmod недостаточно — непривилегированный процесс может сам загрузить модуль, создав SCTP-сокет, поэтому без блокировки автозагрузки узел остаётся достижимым для атаки.

• Загружен ли модуль sctp сейчас:

  $ lsmod | grep -E '^sctp'
  

  Если строка есть, модуль загружен, узел в экспозиции. Если вывод пуст, модуль сейчас не загружен — проверьте блокировку автозагрузки.

• Заблокирована ли автозагрузка:

  $ cat /etc/modprobe.d/blacklist-sctp.conf 2>/dev/null
  # install sctp /bin/false
  # install sctp_diag /bin/false
  # blacklist sctp
  # blacklist sctp_diag
  
  $ modprobe sctp
  

  Наличие директив install/blacklist и ошибка при modprobe sctp означают, что блокировка работает. Вектор недоступен, только если модуль не загружен и автозагрузка заблокирована.

• Собрано ли ядро со встроенной поддержкой SCTP:

  $ grep CONFIG_IP_SCTP /boot/config-$(uname -r)
  

  Значение =y — SCTP встроен в ядро, блокировка модуля неприменима, требуется обновление ядра. Значение =m — SCTP собран модулем, блокировка применима.

• Проверка нагрузок в кластере Yandex Managed Service for Kubernetes^®, которые используют SCTP и будут затронуты блокировкой модуля:

  $ kubectl get svc -A -o json | jq -r '.items[] | select(.spec.ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'
  $ kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].ports[]?.protocol=="SCTP") | "\(.metadata.namespace)/\(.metadata.name)"'
  $ kubectl get netpol -A -o json | jq -r '.items[] | select((.spec.ingress[]?.ports[]?.protocol=="SCTP") or (.spec.egress[]?.ports[]?.protocol=="SCTP")) | "\(.metadata.namespace)/\(.metadata.name)"'
  

• Проверка доступности SCTP-сокета:

$ python3 -c 'import socket; socket.socket(socket.AF_INET, socket.SOCK_STREAM, 132); print("SCTP available")'

Вывод SCTP available — сокет доступен, вектор в экспозиции. Ошибка OSError: Protocol not supported — SCTP на узле недоступен.

Митигации

Основная мера защиты — блокировка модуля sctp, которая полностью отключает SCTP. Для большинства нагрузок это безопасно, но если ваша нагрузка использует SCTP (телеком, VoIP, сигнализация SS7/Diameter), блокировка сломает её трафик — в этом случае не блокируйте модуль, а обновите ядро. Перед применением проверьте зависимость от SCTP командами из раздела с рекомендациями выше.

Yandex Managed Service for Kubernetes^®

• Kubernetes и сетевые плагины (Cilium, Calico) SCTP не используют, поэтому для большинства кластеров блокировка безопасна. Проверьте, есть ли в кластере объекты с protocol: SCTP (Service, NetworkPolicy, порты подов) — командами из раздела с рекомендациями выше. Если такие объекты есть и SCTP вам нужен, не применяйте DaemonSet — дождитесь ревизии образа узла с исправленным ядром.
• Ревизия образа узла с исправленным ядром на момент публикации ещё не выпущена, поэтому основная мера — защитный DaemonSet из репозитория yc-mk8s-sctphantom-mitigation: kubectl apply -f sctphantom-mitigation-daemonset.yaml. DaemonSet пассивно проверяет состояние модулей, не открывая SCTP-сокет, ставит блокировку и при отсутствии живых SCTP-соединений выгружает модули. Успех — вывод mitigation applied successfully; если модуль уже резидентен и не выгружается — вывод mitigation applied PARTIALLY, блокировка стоит, но до перезагрузки узел остается уязвимым.
• На узле, где модуль sctp уже загружен, выгрузить его чаще всего не удаётся: rmmod возвращает ERROR: Module sctp is in use даже при отсутствии активных соединений — ненулевой счётчик ссылок не означает фактического использования модуля. Блокировка сработает только после перезагрузки узла или пересоздания группы узлов Yandex Managed Service for Kubernetes^®. Найти узлы с частичной защитой: kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix --prefix | grep -E 'PARTIALLY|STILL LOADED'.
• Постоянное решение — исправленное ядро, которое приедет новой ревизией образа узла в рамках текущей версии Kubernetes (без перехода на новую минорную версию). Обновления безопасности выпускаются только для трёх последних версий Kubernetes.

Yandex Compute Cloud

• На отдельной виртуальной машине угроза — локальное повышение привилегий до root. Временная мера до обновления ядра — записать конфигурацию блокировки и выгрузить модули вручную. Нужны обе директивы одновременно: blacklist закрывает автозагрузку по alias, install ... /bin/false — явный вызов modprobe. Порядок выгрузки важен — sctp_diag зависит от sctp:

  # sudo sh -c 'printf "install sctp /bin/false\ninstall sctp_diag /bin/false\nblacklist sctp\nblacklist sctp_diag\n" > /etc/modprobe.d/blacklist-sctp.conf; rmmod sctp_diag 2>/dev/null; rmmod sctp 2>/dev/null; if lsmod | grep -qE "^sctp "; then echo "STILL-LOADED refcnt=$(cat /sys/module/sctp/refcnt)"; else echo "UNLOADED-OK"; fi'
  

  UNLOADED-OK — модули выгружены, мера применена. STILL-LOADED — модуль резидентен, перезагрузить виртуальную машину для полного закрытия.

• Постоянное решение — обновить ядро до версии с исправлением (6.6.148, 6.12.101, 6.18.42, 7.1.6, 7.2-rc5) или до бэкпорта вендора дистрибутива.

Общие меры

• Ограничьте размещение недоверенных нагрузок на узлах с загруженным модулем sctp: эксплойту нужен локальный непривилегированный доступ, поэтому не размещайте недоверенные нагрузки рядом с доверенными и по возможности выносите их на отдельные группы узлов.
• Контролируйте конфигурации и обновления узлов: централизованный сбор журналов через Yandex Monium Logs, аудит изменений через Yandex Audit Trails. Проверяйте состояние модулей на узлах после обновлений и масштабирования.
• При обнаружении проблем обратитесь в техническую поддержку.

Дополнительные материалы

• NVD
• CVE. Идентификатор CVE (CVE ID): CVE-2026-64564
• Tencent Zhuque Lab. SCTPhantom: An 18-Year-Old SCTP ASCONF Transport Use-After-Free.
• Yandex Cloud. SCTPhantom Mitigation for Managed Kubernetes.