Mitigação do SCTPhantom para Yandex Managed Kubernetes

Aplicação automática de mitigação para a vulnerabilidade CVE-2026-64564 (SCTPhantom) no kernel Linux em todos os worker-nodes do cluster Yandex Managed Kubernetes.

Descrição da vulnerabilidade

Identificador CVE (CVE ID): CVE-2026-64564

Link do CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-64564

Relatório original:

• Write-up técnico (Tencent Zhuque Lab / Corvus AI): https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564
• PoC público (LPE no Debian 13, kernel 6.12.95): https://github.com/ethanolgolf/CVE-2026-64564
• Fix upstream (mainline): commit 9b2854f86f0b em net/sctp/sm_make_chunk.c

Breve descrição:

SCTPhantom é um use-after-free no subsistema SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) do kernel Linux que permite a um usuário local não privilegiado obter privilégios de superusuário (root).

A causa raiz é uma divergência de identidades no processamento do chunk ASCONF: a verificação da operação DEL-IP é feita contra o endereço de origem do pacote IPv4 (S), enquanto o processamento posterior usa o transport selecionado via Address Parameter (L). Por causa disso, a sequência ordenada

[ Address Parameter L ] [ DEL-IP L ] [ DEL-IP 0.0.0.0 ]

passa na verificação e remove transport(L), após o que a operação wildcard DEL-IP 0.0.0.0 reutiliza o ponteiro já liberado como um "caminho persistente". Como resultado, asoc->peer.primary_path e asoc->peer.active_path permanecem como ponteiros pendentes para o struct sctp_transport liberado, e a chamada subsequente a getsockopt(SCTP_STATUS) os desreferencia.

A lógica vulnerável foi introduzida no Linux 2.6.25 (ano de 2007, commit 42e30bf3463c), ou seja, está presente no kernel há cerca de 18 anos.

Ataque:

• não requer acesso remoto — apenas uma conta local não privilegiada
• não requer CAP_NET_ADMIN nem CAP_SYS_ADMIN, funciona com o perfil seccomp padrão ativo; ASCONF e AUTH são habilitados por socket via SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, portanto não é necessário alterar o sysctl net.sctp.addip_enable
• é um primitivo funcional de escape de contêiner para o host: os autores obtiveram host-root em 6 de 8 tentativas; o passo final é call_usermodehelper_exec(), que executa um processo nos initial namespaces do host
• em caso de exploração mal-sucedida, encerra "limpo", sem kernel panic, o que dificulta a detecção
• a cadeia do exploit reutiliza código existente do kernel (commit_creds() orientado a dados), sem shellcode e sem ROP clássico

Tecnologias afetadas:

• Kernel Linux, subsistema net/sctp (módulo sctp), processamento de ASCONF em net/sctp/sm_make_chunk.c
• Módulo sctp_diag (depende de sctp), usado para inspeção de sockets SCTP

A vulnerabilidade só é explorável se o SCTP estiver disponível: se o módulo sctp não estiver carregado e seu carregamento automático estiver bloqueado, o vetor fica indisponível.

Alvos confirmados pelos autores (root obtido):

Distribuição	Kernel
Kernel de pesquisa	Linux 7.2-rc2
Família OpenCloudOS	6.6.119
Debian 13	6.12.95+deb13-amd64
Rocky Linux 9 / RHEL 9	kernel do fornecedor 5.14 (com o módulo sctp carregado)
Ubuntu 24.04	6.8.0-134-generic

Versões corrigidas do kernel:

Ramo	Primeira versão corrigida	Fix estável
6.6.y	6.6.148	fedeb4468987
6.12.y	6.12.101	74e8f3e7114f
6.18.y	6.18.42	85aca407c560
7.1.y	7.1.6	d136b29bf91d
mainline	7.2-rc5	9b2854f86f0b

Kernels de fornecedores podem conter um backport do fix mesmo com uma versão mais antiga na string de versão — a versão do kernel em si não é um indicador suficiente de vulnerabilidade; baseie-se no advisory ou nos fontes do fornecedor.

Vetor de ataque e nível de gravidade de acordo com o CVSS v.4.0:

Pontuação base: 8.5 (HIGH)

Vetor: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

O que este fix faz

O DaemonSet, automaticamente, em cada worker node do cluster:

1. Verifica o estado dos módulos — verifica se sctp e sctp_diag estão carregados e com qual refcnt. A verificação é intencionalmente passiva: o DaemonSet não abre socket SCTP antes de aplicar a blacklist, para não provocar o carregamento automático do módulo em um nó onde ele ainda não está carregado
2. Verifica se o SCTP está em uso no nó — analisa o refcnt do módulo e as entradas ativas em /proc/net/sctp/assocs e /proc/net/sctp/eps. O próprio Kubernetes não usa SCTP, mas cargas de trabalho do usuário podem declarar protocol: SCTP em Service/Pod
3. Bloqueia os módulos vulneráveis — cria /etc/modprobe.d/blacklist-sctp.conf com regras install e blacklist para sctp e sctp_diag
4. Descarrega os módulos — executa rmmod para sctp_diag e depois para sctp (a ordem é importante: sctp_diag depende de sctp). Se forem detectadas conexões SCTP ativas, o descarregamento é ignorado, a menos que FORCE_APPLY=true seja definido explicitamente
5. Verifica a mitigação — confirma a presença da configuração, que modprobe sctp é rejeitado e que a criação de socket SCTP (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) não passa mais
6. Monitora o estado — a cada hora verifica a presença da configuração, restaura-a caso desapareça e descarrega novamente os módulos se eles forem carregados de novo

Importante: dois resultados possíveis no nó

A mitigação consiste em duas partes independentes, e em parte dos nós apenas uma delas é aplicada.

1. Blacklist (aplicada sempre, de forma confiável). Após a criação de /etc/modprobe.d/blacklist-sctp.conf, o módulo sctp não pode mais ser carregado — nem automaticamente ao chamar socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP), nem por modprobe explícito. Isso fecha o vetor em nós onde o módulo ainda não foi carregado (estado típico: o SCTP não é usado pelo Kubernetes e só é carregado sob demanda).

2. Descarregamento do módulo da memória (nem sempre possível). Se o sctp já estiver carregado, na maioria dos casos não será possível descarregá-lo. Em nós testados do Yandex Managed Kubernetes (Ubuntu 22.04, kernel 5.15.0-181-generic), o módulo sctp recém-carregado e não utilizado por ninguém já apresenta refcnt=6 com lista de holders vazia e /proc/net/sctp/{assocs,eps} vazios, e o rmmod retorna ERROR: Module sctp is in use. O contador não diminui com o tempo.

Daí duas consequências:

• refcnt não é um indicador de uso do SCTP — o DaemonSet o exibe apenas de forma informativa, e a decisão de descarregar é tomada com base nas entradas ativas em /proc/net/sctp/assocs e /proc/net/sctp/eps
• em um nó onde o sctp já está residente, o DaemonSet reporta honestamente ⚠ mitigation applied PARTIALLY. A blacklist já está aplicada ali (após a reinicialização, o módulo não voltará), mas até a reinicialização o nó permanece vulnerável. Para fechar completamente o vetor, esses nós precisam ser reiniciados ou a node group precisa ser recriada

Para encontrar esses nós após a implantação:

kubectl logs -n kube-system -l app=cve-2026-64564-fix -c apply-fix --prefix | grep -E 'PARTIALLY|STILL LOADED'

Compatibilidade com cargas de trabalho

Importante: a mitigação desativa completamente o SCTP no nó.

O Kubernetes e os plugins de rede (Cilium, Calico) não usam SCTP para o próprio funcionamento, portanto, para a grande maioria dos clusters, a mitigação é segura. No entanto, se houver no cluster alguma carga de trabalho que use SCTP (por exemplo, aplicações de telecom, VoIP/sinalização SS7/Diameter, Service ou NetworkPolicy com protocol: SCTP), o tráfego dela deixará de funcionar.

Antes de implantar, verifique se existem esses objetos no cluster: