Atténuation de SCTPhantom pour Yandex Managed Kubernetes

Application automatique de l'atténuation pour la vulnérabilité CVE-2026-64564 (SCTPhantom) dans le noyau Linux sur tous les nœuds worker du cluster Yandex Managed Kubernetes.

Description de la vulnérabilité

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

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

Rapport d'origine :

• Write-up technique (Tencent Zhuque Lab / Corvus AI) : https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564
• PoC public (LPE sous Debian 13, noyau 6.12.95) : https://github.com/ethanolgolf/CVE-2026-64564
• Correctif upstream (mainline) : commit 9b2854f86f0b dans net/sctp/sm_make_chunk.c

Description succincte :

SCTPhantom est un use-after-free dans le sous-système SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) du noyau Linux, permettant à un utilisateur local non privilégié d'obtenir les droits de superutilisateur (root).

La cause racine est une divergence d'identités lors du traitement du chunk ASCONF : la vérification de l'opération DEL-IP est effectuée contre l'adresse source du paquet IPv4 (S), tandis que le traitement ultérieur utilise le transport sélectionné via l'Address Parameter (L). De ce fait, la séquence ordonnée

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

passe la vérification et supprime transport(L), après quoi l'opération wildcard DEL-IP 0.0.0.0 réutilise le pointeur déjà libéré comme « chemin conservé ». En conséquence, asoc->peer.primary_path et asoc->peer.active_path restent des pointeurs pendants vers le struct sctp_transport libéré, et l'appel suivant à getsockopt(SCTP_STATUS) les déréférence.

La logique vulnérable a été introduite dans Linux 2.6.25 (année 2007, commit 42e30bf3463c), soit environ 18 ans de présence dans le noyau.

Attaque :

• ne nécessite pas d'accès distant - seulement un compte local non privilégié
• ne nécessite pas CAP_NET_ADMIN ni CAP_SYS_ADMIN, fonctionne lorsque le profil seccomp par défaut est actif ; ASCONF et AUTH sont activés par socket via SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, il n'est donc pas nécessaire de modifier le sysctl net.sctp.addip_enable
• constitue une primitive fonctionnelle d'évasion de conteneur vers l'hôte : les auteurs ont obtenu un root hôte dans 6 essais sur 8, l'étape finale étant call_usermodehelper_exec(), qui lance un processus dans les initial namespaces de l'hôte
• en cas d'échec de l'exploitation, elle se termine « proprement », sans kernel panic, ce qui complique la détection
• la chaîne d'exploitation réutilise le code noyau existant (commit_creds() orienté données), sans shellcode ni ROP classique

Technologies concernées :

• Noyau Linux, sous-système net/sctp (module sctp), traitement d'ASCONF dans net/sctp/sm_make_chunk.c
• Module sctp_diag (dépend de sctp), utilisé pour l'inspection des sockets SCTP

La vulnérabilité n'est exploitable que si SCTP est disponible : si le module sctp n'est pas chargé et que son chargement automatique est bloqué, le vecteur n'est pas accessible.

Cibles confirmées par les auteurs (root obtenu) :

Distribution	Noyau
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 noyau du fournisseur (lorsque le module sctp est chargé)
Ubuntu 24.04	6.8.0-134-generic

Versions de noyau corrigées :

Branche	Première version corrigée	Correctif stable
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

Les noyaux des fournisseurs peuvent contenir un backport du correctif avec une version plus ancienne dans la chaîne de version - la version du noyau elle-même n'est pas un indicateur suffisant de vulnérabilité, fiez-vous à l'advisory ou aux sources du fournisseur.

Vecteur d'attaque et niveau de gravité selon CVSS v4.0 :

Score de base : 8.5 (HIGH)

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

Ce que fait ce correctif

Le DaemonSet, automatiquement sur chaque nœud worker du cluster :

1. Vérifie l'état des modules - regarde si sctp et sctp_diag sont chargés, et avec quel refcnt. La vérification est volontairement passive : le DaemonSet n'ouvre pas de socket SCTP avant la mise en place de la blacklist, afin de ne pas déclencher le chargement automatique du module sur un nœud où il n'est pas encore chargé
2. Vérifie si SCTP est utilisé sur le nœud - analyse le refcnt du module et les entrées vivantes dans /proc/net/sctp/assocs et /proc/net/sctp/eps. Kubernetes lui-même n'utilise pas SCTP, mais une charge de travail utilisateur peut déclarer protocol: SCTP dans des Service/Pod
3. Bloque les modules vulnérables - crée /etc/modprobe.d/blacklist-sctp.conf avec les règles install et blacklist pour sctp et sctp_diag
4. Décharge les modules - exécute rmmod pour sctp_diag, puis sctp (l'ordre est important : sctp_diag dépend de sctp). Si des connexions SCTP vivantes sont détectées, le déchargement est ignoré, sauf si FORCE_APPLY=true est explicitement défini
5. Vérifie l'atténuation - contrôle que la configuration est présente, que modprobe sctp est rejeté, et que la création d'une socket SCTP (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) n'aboutit plus
6. Surveille l'état - vérifie toutes les heures la présence de la configuration, la restaure si elle disparaît et décharge à nouveau les modules s'ils se retrouvent chargés

Important : deux issues possibles sur un nœud

L'atténuation se compose de deux parties indépendantes, et sur certains nœuds, seule l'une d'elles est appliquée.

1. Blacklist (toujours appliquée, fiable). Après la création de /etc/modprobe.d/blacklist-sctp.conf, le module sctp ne peut plus être chargé - ni automatiquement lors d'un socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP), ni par un modprobe explicite. Cela ferme le vecteur sur les nœuds où le module n'était pas encore chargé (état typique : SCTP n'est pas utilisé par Kubernetes et n'est chargé qu'à la demande).

2. Déchargement du module de la mémoire (pas toujours possible). Si sctp est déjà chargé, le décharger ne sera généralement pas possible. Sur les nœuds testés de Yandex Managed Kubernetes (Ubuntu 22.04, noyau 5.15.0-181-generic), un module sctp fraîchement chargé et utilisé par personne a déjà refcnt=6 avec une liste de holders vide et des /proc/net/sctp/{assocs,eps} vides, et rmmod renvoie ERROR: Module sctp is in use. Le compteur ne diminue pas avec le temps.

D'où deux conséquences :

• refcnt n'est pas un indicateur d'utilisation de SCTP - le DaemonSet ne l'affiche qu'à titre informatif et prend la décision de déchargement en fonction des entrées vivantes dans /proc/net/sctp/assocs et /proc/net/sctp/eps
• sur un nœud où sctp est déjà résident, le DaemonSet signale honnêtement ⚠ mitigation applied PARTIALLY. La blacklist y est déjà en place (après un redémarrage, le module ne reviendra pas), mais jusqu'au redémarrage, le nœud reste vulnérable. Pour fermer complètement le vecteur, ces nœuds doivent être redémarrés ou le groupe de nœuds doit être recréé

Pour trouver ces nœuds après le déploiement :

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

Compatibilité avec les charges de travail

Important : l'atténuation désactive complètement SCTP sur le nœud.