Mitigación de SCTPhantom para Yandex Managed Kubernetes

Aplicación automática de la mitigación para la vulnerabilidad CVE-2026-64564 (SCTPhantom) en el kernel de Linux en todos los worker nodes del clúster Yandex Managed Kubernetes.

Descripción de la vulnerabilidad

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

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

Informe 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 en Debian 13, kernel 6.12.95): https://github.com/ethanolgolf/CVE-2026-64564
• Fix upstream (mainline): commit 9b2854f86f0b en net/sctp/sm_make_chunk.c

Breve descripción:

SCTPhantom es un use-after-free en el subsistema SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) del kernel de Linux que permite a un usuario local no privilegiado obtener privilegios de superusuario (root).

La causa raíz es una discrepancia de identidades al procesar el chunk ASCONF: la verificación de la operación DEL-IP se realiza contra la dirección de origen del paquete IPv4 (S), mientras que el procesamiento posterior utiliza el transport seleccionado mediante el Address Parameter (L). Debido a esto, la secuencia ordenada

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

supera la verificación y elimina transport(L), tras lo cual la operación wildcard DEL-IP 0.0.0.0 reutiliza el puntero ya liberado como «ruta conservada». Como resultado, asoc->peer.primary_path y asoc->peer.active_path quedan como punteros colgantes al struct sctp_transport liberado, y la posterior llamada a getsockopt(SCTP_STATUS) los desreferencia.

La lógica vulnerable se introdujo en Linux 2.6.25 (año 2007, commit 42e30bf3463c), es decir, está presente en el kernel desde hace unos 18 años.

Ataque:

• no requiere acceso remoto: solo una cuenta local no privilegiada
• no requiere CAP_NET_ADMIN ni CAP_SYS_ADMIN; funciona con el perfil seccomp predeterminado activo; ASCONF y AUTH se habilitan por socket mediante SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, por lo que no es necesario cambiar el sysctl net.sctp.addip_enable
• es un primitivo funcional de escape de contenedor al host: los autores obtuvieron host-root en 6 de 8 intentos; el paso final es call_usermodehelper_exec(), que lanza un proceso en los namespaces iniciales del host
• ante un intento fallido termina de forma «limpia», sin kernel panic, lo que dificulta la detección
• la cadena del exploit reutiliza código existente del kernel (commit_creds() orientado a datos), sin shellcode ni ROP clásico

Tecnologías afectadas:

• Kernel de Linux, subsistema net/sctp (módulo sctp), procesamiento de ASCONF en net/sctp/sm_make_chunk.c
• El módulo sctp_diag (depende de sctp) se utiliza para inspeccionar sockets SCTP

La vulnerabilidad solo es explotable si SCTP está disponible: si el módulo sctp no está cargado y su autocarga está bloqueada, el vector no está disponible.

Objetivos confirmados por los autores (se obtuvo root):

Distribución	Kernel
Research kernel	Linux 7.2-rc2
OpenCloudOS-family	6.6.119
Debian 13	6.12.95+deb13-amd64
Rocky Linux 9 / RHEL 9	5.14 vendor kernel (con el módulo sctp cargado)
Ubuntu 24.04	6.8.0-134-generic

Versiones del kernel corregidas:

Rama	Primera versión corregida	Fix estable
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

Los kernels de proveedor pueden contener un backport del fix incluso con una versión más antigua en la cadena de versión; la propia versión del kernel no es un indicador suficiente de vulnerabilidad; consulte el advisory o las fuentes del proveedor.

Vector de ataque y nivel de peligro según CVSS v.4.0:

Puntuación base: 8.5 (HIGH)

Vector: 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

Qué hace este fix

El DaemonSet automáticamente, en cada worker node del clúster:

1. Comprueba el estado de los módulos: observa si sctp y sctp_diag están cargados y con qué refcnt. La comprobación es deliberadamente pasiva: el DaemonSet no abre un socket SCTP antes de establecer la blacklist, para no provocar la autocarga del módulo en un nodo donde aún no está cargado
2. Comprueba si SCTP se usa en el nodo: analiza el refcnt del módulo y las entradas vivas en /proc/net/sctp/assocs y /proc/net/sctp/eps. Kubernetes en sí no usa SCTP, pero las cargas de trabajo de usuario pueden declarar protocol: SCTP en Service/Pod
3. Bloquea los módulos vulnerables: crea /etc/modprobe.d/blacklist-sctp.conf con reglas install y blacklist para sctp y sctp_diag
4. Descarga los módulos: ejecuta rmmod para sctp_diag y luego sctp (el orden es importante: sctp_diag depende de sctp). Si se detectan conexiones SCTP vivas, se omite la descarga a menos que se establezca explícitamente FORCE_APPLY=true
5. Verifica la mitigación: comprueba la existencia de la configuración, que modprobe sctp sea rechazado y que la creación de un socket SCTP (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) ya no sea posible
6. Supervisa el estado: cada hora comprueba la presencia de la configuración, la restaura si desaparece y vuelve a descargar los módulos si han vuelto a cargarse

Importante: dos posibles resultados en el nodo

La mitigación consta de dos partes independientes y en algunos nodos solo se aplica una de ellas.

1. Blacklist (se aplica siempre, de forma fiable). Tras crear /etc/modprobe.d/blacklist-sctp.conf, el módulo sctp ya no puede cargarse, ni automáticamente con socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP), ni mediante modprobe explícito. Esto cierra el vector en los nodos donde el módulo aún no se había cargado (estado típico: SCTP no lo usa Kubernetes y solo se carga bajo demanda).

2. Descarga del módulo de memoria (no siempre es posible). Si sctp ya estaba cargado, en la mayoría de los casos no se podrá descargar. En los nodos probados de Yandex Managed Kubernetes (Ubuntu 22.04, kernel 5.15.0-181-generic), el módulo sctp recién cargado y no utilizado por nadie ya tiene refcnt=6 con una lista de holders vacía y /proc/net/sctp/{assocs,eps} vacíos, y rmmod devuelve ERROR: Module sctp is in use. El contador no disminuye con el tiempo.

De aquí se derivan dos consecuencias:

• refcnt no es un indicador de uso de SCTP: el DaemonSet lo muestra solo con fines informativos y decide la descarga basándose en las entradas vivas en /proc/net/sctp/assocs y /proc/net/sctp/eps
• en un nodo donde sctp ya es residente, el DaemonSet informa honestamente ⚠ mitigation applied PARTIALLY. Allí ya está la blacklist (tras un reinicio el módulo no volverá), pero hasta el reinicio el nodo sigue siendo vulnerable. Para cerrar el vector por completo, estos nodos deben reiniciarse o debe recrearse el node group

Para encontrar estos nodos tras el despliegue:

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

Compatibilidad con cargas de trabajo

Importante: la mitigación desactiva SCTP por completo en el nodo.

Kubernetes y los plugins de red (Cilium, Calico) no usan SCTP para su propio funcionamiento, por lo que la mitigación es segura para la gran mayoría de los clústeres. Sin embargo, si en el clúster hay cargas que usan SCTP (por ejemplo, aplicaciones de telecomunicaciones, VoIP/señalización SS7/Diameter, Service o NetworkPolicy con protocol: SCTP), su tráfico dejará de funcionar.

Para comprobar si existen tales objetos en el clúster antes del despliegue: