SCTPhantom Mitigation for Yandex Managed Kubernetes

Applicazione automatica della mitigazione per la vulnerabilità CVE-2026-64564 (SCTPhantom) nel kernel Linux su tutti i worker node del cluster Yandex Managed Kubernetes.

Descrizione della vulnerabilità

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

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

Report originale:

• Write-up tecnico (Tencent Zhuque Lab / Corvus AI): https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564
• PoC pubblico (LPE su Debian 13, kernel 6.12.95): https://github.com/ethanolgolf/CVE-2026-64564
• Fix upstream (mainline): commit 9b2854f86f0b in net/sctp/sm_make_chunk.c

Breve descrizione:

SCTPhantom è un use-after-free nella sottosistema SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) del kernel Linux che consente a un utente locale non privilegiato di ottenere i privilegi di superutente (root).

La causa principale è la divergenza delle identità nell'elaborazione del chunk ASCONF: il controllo dell'operazione DEL-IP viene eseguito contro l'indirizzo sorgente del pacchetto IPv4 (S), mentre l'elaborazione successiva utilizza il transport selezionato tramite l'Address Parameter (L). Di conseguenza, la sequenza ordinata

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

supera il controllo e rimuove transport(L), dopodiché l'operazione wildcard DEL-IP 0.0.0.0 riutilizza il puntatore già liberato come "percorso preservato". Di conseguenza asoc->peer.primary_path e asoc->peer.active_path restano puntatori dangling a una struct sctp_transport liberata, e la successiva chiamata getsockopt(SCTP_STATUS) li dereferenzia.

La logica vulnerabile è stata introdotta in Linux 2.6.25 (2007, commit 42e30bf3463c), quindi è presente nel kernel da circa 18 anni.

Attacco:

• non richiede accesso remoto: basta un account locale non privilegiato
• non richiede CAP_NET_ADMIN e CAP_SYS_ADMIN, funziona con il profilo seccomp predefinito attivo; ASCONF e AUTH vengono abilitati per-socket tramite SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, quindi non è necessario modificare il sysctl net.sctp.addip_enable
• è un primitivo funzionante di escape dal container all'host: gli autori hanno ottenuto host-root in 6 tentativi su 8, il passo finale è call_usermodehelper_exec(), che avvia un processo nei namespace iniziali dell'host
• in caso di exploit fallito termina in modo pulito, senza kernel panic, il che rende difficile il rilevamento
• la catena dell'exploit riutilizza codice kernel esistente (commit_creds() data-oriented), senza shellcode e senza ROP classico

Tecnologie interessate:

• Kernel Linux, sottosistema net/sctp (modulo sctp), elaborazione di ASCONF in net/sctp/sm_make_chunk.c
• Modulo sctp_diag (dipende da sctp), usato per l'ispezione dei socket SCTP

La vulnerabilità è sfruttabile solo se SCTP è disponibile: se il modulo sctp non è caricato e il suo caricamento automatico è bloccato, il vettore non è disponibile.

Obiettivi confermati dagli autori (root ottenuta):

Distribuzione	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 modulo sctp caricato)
Ubuntu 24.04	6.8.0-134-generic

Versioni del kernel corrette:

Ramo	Prima versione corretta	Fix stabile
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

I kernel vendor possono contenere un backport del fix con una versione più vecchia nella stringa di versione: la versione del kernel da sola non è un indicatore sufficiente di vulnerabilità; fare riferimento all'advisory o ai sorgenti del vendor.

Vettore d'attacco e livello di pericolosità secondo CVSS v.4.0:

Punteggio base: 8.5 (HIGH)

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

Cosa fa questo fix

Il DaemonSet, automaticamente su ogni worker node del cluster:

1. Verifica lo stato dei moduli - controlla se sctp e sctp_diag sono caricati e con quale refcnt. Il controllo è volutamente passivo: il DaemonSet non apre socket SCTP prima di impostare la blacklist, per non provocare il caricamento automatico del modulo su un nodo dove non è ancora caricato
2. Verifica se SCTP è utilizzato sul nodo - analizza il refcnt del modulo e le voci attive in /proc/net/sctp/assocs e /proc/net/sctp/eps. Kubernetes stesso non usa SCTP, ma i carichi di lavoro utente possono dichiarare protocol: SCTP in Service/Pod
3. Blocca i moduli vulnerabili - crea /etc/modprobe.d/blacklist-sctp.conf con le regole install e blacklist per sctp e sctp_diag
4. Scarica i moduli - esegue rmmod per sctp_diag, poi sctp (l'ordine è importante: sctp_diag dipende da sctp). Se vengono rilevate connessioni SCTP attive, lo scaricamento viene saltato, a meno che non sia impostato esplicitamente FORCE_APPLY=true
5. Verifica la mitigazione - controlla la presenza della configurazione, che modprobe sctp venga rifiutato e che la creazione di un socket SCTP (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) non riesca più
6. Monitora lo stato - ogni ora verifica la presenza della configurazione, la ripristina se scompare e scarica di nuovo i moduli se risultano di nuovo caricati

Importante: due possibili esiti sul nodo

La mitigazione è composta da due parti indipendenti e su alcuni nodi viene applicata solo una di esse.

1. Blacklist (applicata sempre, in modo affidabile). Dopo la creazione di /etc/modprobe.d/blacklist-sctp.conf, il modulo sctp non può più essere caricato - né automaticamente con socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP), né con modprobe esplicito. Questo chiude il vettore sui nodi in cui il modulo non era ancora stato caricato (stato tipico: SCTP non è usato da Kubernetes e viene caricato solo su richiesta).

2. Scaricamento del modulo dalla memoria (non sempre possibile). Se sctp è già stato caricato, nella maggior parte dei casi non sarà possibile scaricarlo. Sui nodi Yandex Managed Kubernetes testati (Ubuntu 22.04, kernel 5.15.0-181-generic), un modulo sctp appena caricato e non utilizzato da nessuno ha già refcnt=6 con lista holders vuota e /proc/net/sctp/{assocs,eps} vuoti, e rmmod restituisce ERROR: Module sctp is in use. Il contatore non diminuisce nel tempo.

Da qui due conseguenze:

• refcnt non è un indicatore dell'uso di SCTP: il DaemonSet lo mostra solo a scopo informativo e decide sullo scaricamento in base alle voci attive in /proc/net/sctp/assocs e /proc/net/sctp/eps
• su un nodo in cui sctp è già residente, il DaemonSet segnala onestamente ⚠ mitigation applied PARTIALLY. La blacklist è già presente (dopo il riavvio il modulo non tornerà), ma fino al riavvio il nodo rimane vulnerabile. Per chiudere completamente il vettore, questi nodi devono essere riavviati oppure si deve ricreare il node group

Per trovare questi nodi dopo il rollout:

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

Compatibilità con i carichi di lavoro

Importante: la mitigazione disattiva completamente SCTP sul nodo.

Kubernetes e i plugin di rete (Cilium, Calico) non usano SCTP per il proprio funzionamento, quindi per la stragrande maggioranza dei cluster la mitigazione è sicura. Tuttavia, se nel cluster sono presenti carichi di lavoro che usano SCTP (ad esempio applicazioni telecom, VoIP/segnale SS7/Diameter, Service o NetworkPolicy con protocol: SCTP), il loro traffico smetterà di funzionare.

Per verificare se nel cluster esistono tali oggetti, prima del rollout: