Rapport CTI technique du 8 août 2026
Résumé exécutif
Tencent Zhuque Lab a publié le 6 août 2026 les détails complets de SCTPhantom, un use-after-free dans le code de reconfiguration dynamique d'adresses (ASCONF) du sous-système SCTP du noyau Linux. La faille, tracée CVE-2026-64564 et notée 8.5 en CVSS v4.0 par ses découvreurs, trouve son origine dans un commit de décembre 2007 (Linux 2.6.25) : elle est donc présente dans toutes les versions du noyau publiées depuis dix-huit ans. L'équipe CVE du noyau Linux a formellement annoncé la faille le 4 août 2026, et les correctifs sont disponibles depuis le 3 août dans les branches stables 6.6.148, 6.12.101, 6.18.42 et 7.1.6.
Le laboratoire, s'appuyant sur son pipeline de recherche multi-agent Corvus AI, a développé une chaîne d'exploitation complète menant à un accès root global sur cinq distributions testées (Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, OpenCloudOS) et démontré une évasion de conteneur vers l'hôte sur six tentatives sur huit, sans capacités CAP_NET_ADMIN ni CAP_SYS_ADMIN et avec le profil seccomp par défaut actif. La faille exige un accès local et la disponibilité du protocole SCTP sur la cible, ce qui limite son exposition directe, mais elle concerne directement tout environnement multi-tenant, hébergement mutualisé ou plateforme de conteneurs exposant SCTP aux charges de travail non fiables. Aucun exploit public n'a circulé à la date de rédaction et la faille n'apparaît pas au catalogue KEV de la CISA.
Chronologie
| Date | Événement |
|---|---|
| Décembre 2007 (Linux 2.6.25) | Introduction du commit 42e30bf3463c, qui complète la séquence vulnérable dans la gestion des adresses génériques ASCONF |
| 12 juillet 2026 | Corvus AI (Tencent Zhuque Lab) identifie la violation de durée de vie du transport ASCONF et engage la divulgation privée avec un PoC reproductible |
| 15 juillet 2026 | Première chaîne stable d'obtention de root global validée |
| 15 au 23 juillet 2026 | Validation de l'exploit sur plusieurs cibles à base de noyaux 5.14, 6.6, 6.8 et 6.12 |
| 24 juillet 2026 | Le correctif entre dans l'arborescence réseau du noyau Linux |
| 27 juillet 2026 | Validation de l'évasion conteneur vers hôte |
| 3 août 2026 | Publication des versions stables corrigées 6.6.148, 6.12.101, 6.18.42 et 7.1.6 |
| 4 août 2026 | L'équipe CVE du noyau Linux annonce officiellement CVE-2026-64564 |
| 6 août 2026 | Tencent Zhuque Lab publie l'analyse technique complète sous le nom SCTPhantom |
Fiche vulnérabilité (format fiche CTI)
CVE-2026-64564 | CVSS v4.0 : 8.5 (High), vecteur AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N | Noyau Linux, sous-système SCTP (net/sctp/sm_make_chunk.c), toutes versions depuis 2.6.25 jusqu'aux correctifs d'août 2026
Description technique : la faille exploite une incohérence d'identité entre deux valeurs utilisées lors du traitement d'un chunk ASCONF (RFC 5061, reconfiguration dynamique d'adresses SCTP). La vérification de suppression DEL-IP valide l'opération contre l'adresse source du paquet IPv4 (S), tandis que le traitement effectif s'appuie sur le transport sélectionné via le paramètre d'adresse du message (L). Un attaquant envoie une séquence ordonnée : un paramètre d'adresse L, une suppression DEL-IP visant L, puis une suppression DEL-IP générique (wildcard). Comme S et L diffèrent, la suppression de L passe la vérification de source et libère le transport correspondant ; la suppression générique qui suit réutilise ensuite le pointeur devenu obsolète comme chemin à conserver dans primary_path et active_path de l'association SCTP. Une opération socket ultérieure déréférence ce pointeur libéré, provoquant le use-after-free (CWE-416).
Conditions d'exploitation : accès local requis (AV:L), avec SCTP joignable sur la cible. L'exploit complet développé par Corvus AI enchaîne : survie contrôlée du UAF via un transport secondaire ACTIVE confirmé, fuite d'une adresse mémoire directe du noyau par réutilisation d'un pg_vec TPACKET V1 dans le slot libéré, lecture arbitraire de 4 octets via le champ assoc_id de SCTP_STATUS, récupération du KASLR via l'IDT en lecture seule de la zone d'entrée CPU, puis construction d'un graphe d'objets noyau contrôlé menant à un appel commit_creds() orienté données, sans shellcode ni chaîne ROP traditionnelle. La variante conteneur ajoute un déclenchement via call_usermodehelper_exec() pour atteindre les espaces de noms initiaux de l'hôte.
PoC disponible : non publié publiquement à la date de rédaction. Tencent Zhuque Lab a communiqué la méthodologie complète et les preuves (captures KASAN, tableaux de résultats par distribution) mais pas le code d'exploitation.
Patch/mitigation : mise à jour vers les versions stables corrigées (6.6.148, 6.12.101, 6.18.42, 7.1.6, ou 7.2-rc5 pour la branche de développement). Le correctif modifie net/sctp/sm_make_chunk.c pour rejeter une suppression visant le transport retenu pour le traitement du chunk ASCONF en cours (commit amont 9b2854f86f0b). À noter : un second use-after-free distinct dans la même zone de code (transport pendant) a été corrigé le 6 août, après la publication des builds stables du 3 août ; ces derniers n'intègrent donc pas ce second correctif. Pour les environnements où SCTP n'est pas nécessaire, désactiver ou bloquer le chargement du module sctp élimine la surface d'attaque sans attendre le déploiement du correctif noyau.
Diagramme de la chaîne d'attaque
Reconstruction technique établie à partir de la publication Tencent Zhuque Lab du 6 août 2026 et du reporting The Hacker News du 7 août 2026.
Analyse technique
Étape 1 : confusion d'identité dans le traitement ASCONF
Le noyau Linux représente une association SCTP via struct sctp_association, avec plusieurs chemins réseau possibles (struct sctp_transport) liés via peer.transport_addr_list. Le bug provient du fait que la validation d'une opération DEL-IP se fait contre l'adresse source du paquet reçu, alors que le transport réellement manipulé est celui désigné par le paramètre d'adresse porté dans le chunk ASCONF lui-même. Ces deux valeurs ne sont normalement pas censées diverger dans un usage légitime, ce qui explique que ce chemin de code soit resté non détecté pendant dix-huit ans.
Étape 2 : libération et réutilisation d'un pointeur obsolète
En envoyant la séquence [Adresse L] [DEL-IP L] [DEL-IP 0.0.0.0] dans un seul chunk ASCONF, l'attaquant fait supprimer le transport L par la première opération, puis la suppression générique qui suit réutilise le pointeur déjà libéré comme chemin à conserver dans les champs primary_path et active_path de l'association. Il en résulte une association SCTP toujours active mais pointant vers de la mémoire noyau libérée.
Étape 3 : primitive de lecture arbitraire via fuite mémoire et détournement de statut
Corvus AI a établi les conditions précises pour faire survivre le UAF (transport secondaire confirmé ACTIVE, désactivation ciblée des heartbeats, blocage de la source usurpée pour empêcher la réallocation automatique du slot). Une fois le pointeur pendant stabilisé, une allocation pg_vec TPACKET V1 de même taille (kmalloc-1024) vient occuper le slot libéré. L'appel getsockopt(SCTP_STATUS) interprète alors des pointeurs de page comme des champs de transport SCTP, ce qui fuit une adresse mémoire physique directe du noyau. En contrôlant ensuite le champ transport->asoc, l'attaquant transforme SCTP_STATUS en primitive de lecture arbitraire de 4 octets à une adresse choisie, ce qui permet de reconstruire le KASLR slide via la table IDT en lecture seule de la zone d'entrée CPU.
Étape 4 : construction d'un graphe d'objets contrôlé et élévation à root
Une seconde association SCTP est utilisée pour placer un objet de taille identique à struct sctp_transport (via une allocation de clé d'authentification SCTP persistante) dans le même cache mémoire que le transport libéré. L'attaquant construit ainsi un faux objet transport, une fausse association, et un faux socket pointant vers une structure de credential contrôlée. Le déclencheur final est un close() en mode abortif (SO_LINGER avec linger=0), qui force une génération de paquet SCTP ABORT, traverse sctp_transport_route(), et invoque la fonction get_saddr() détournée pour appeler commit_creds() avec des credentials contrôlés, obtenant un accès root global vérifié par accès effectif à /etc/shadow et création d'un fichier appartenant à root.
Étape 5 : évasion de conteneur vers l'hôte
Pour les environnements conteneurisés, Corvus AI a identifié un chemin qui ne nécessite ni CAP_NET_ADMIN ni CAP_SYS_ADMIN en activant les fonctionnalités SCTP au niveau du socket plutôt que par sysctl système. Le déclencheur final invoque call_usermodehelper_exec() avec une structure subprocess_info placée dans la page mémoire noyau déjà divulguée, ce qui exécute un processus dans les espaces de noms initiaux de l'hôte, hors du conteneur, avec le profil seccomp par défaut actif.
Indicateurs de compromission
Aucun indicateur réseau ou fichier n'est publié pour cette vulnérabilité : il s'agit d'une faille d'exploitation locale sans trafic distant caractéristique. Les signaux de détection possibles reposent sur la télémétrie noyau et conteneur.
| Type | Valeur |
|---|---|
| Signal noyau | Rapports KASAN ou sanitizer signalant un use-after-free dans sctp_transport_new() ou le callback RCU associé |
| Signal comportemental | Séquences ASCONF contenant un paramètre d'adresse suivi d'un DEL-IP ciblé puis d'un DEL-IP générique (0.0.0.0) sur la même association |
| Signal conteneur | Exécution inattendue d'un processus dans l'espace de noms initial de l'hôte suite à une activité call_usermodehelper_exec() non planifiée |
| Périmètre d'exposition | Toute charge de travail avec accès aux sockets SCTP bruts ou packet, sans restriction stricte des capacités et de la politique seccomp |
MITRE ATT&CK
| Tactique | Technique | ID | Justification |
|---|---|---|---|
| Privilege Escalation | Exploitation for Privilege Escalation | T1068 | Exploitation directe d'un use-after-free noyau pour obtenir des privilèges root depuis un accès local non privilégié |
| Privilege Escalation / Defense Evasion | Escape to Host | T1611 | Évasion de conteneur vers l'hôte démontrée via call_usermodehelper_exec() dans les espaces de noms initiaux |
| Defense Evasion | Exploitation for Defense Evasion | T1211 | Contournement effectif de KASLR et des mêménismes de durcissement noyau (LIST_HARDENED) comme étape intermédiaire de la chaîne |
Cette cartographie est une lecture technique construite à partir de la mêmoire publiée par Tencent Zhuque Lab, aucune cartographie ATT&CK officielle n'ayant été publiée par un éditeur ou une agence gouvernementale pour cette CVE à la date de rédaction.
Remédiation : checklist opérationnelle
- Identifier tous les systèmes exécutant un noyau Linux antérieur aux versions corrigées (6.6.148, 6.12.101, 6.18.42, 7.1.6) et planifier leur mise à jour en priorité sur les hôtes multi-tenant et les nœuds de conteneurs.
- Sur les systèmes ne pouvant être patchés immédiatement, désactiver le chargement du module noyau sctp si le protocole n'est pas requis (install sctp /bin/false ou blocage équivalent).
- Restreindre l'accès aux sockets SCTP bruts et packet dans les environnements conteneurisés via des politiques seccomp et des profils de capacités stricts, même si le PoC de Tencent démontre une voie sans CAP_NET_ADMIN ni CAP_SYS_ADMIN.
- Vérifier que le correctif appliqué couvre également le second use-after-free corrigé le 6 août 2026 dans la même zone de code, publié après les builds stables du 3 août.
- Sur les plateformes vendor (distributions dérivées, appliances), ne pas se fier au seul numéro de version du noyau : consulter l'avis ou le paquet source du fournisseur pour confirmer le statut du correctif, les correctifs étant fréquemment rétroportés sans changement de version affichée.
- Déployer une détection basée sur la télémétrie noyau (KASAN en environnement de test, eBPF en production) pour repérer des séquences ASCONF anormales combinant paramètre d'adresse et double DEL-IP.
- Sur les hôtes de conteneurs critiques, auditer les exécutions call_usermodehelper_exec() inattendues comme signal de compromission tardive.
- Documenter l'inventaire des services exposant SCTP (téléphonie, signalisation, certains équipements télécoms) pour prioriser le correctif sur ce périmètre spécifique.
