Une faille Linux SCTP de type use-after-free a été mise en avant par des chercheurs : elle permettrait, dans certains scénarios, à un utilisateur local d’obtenir des privilèges root sur la machine hôte et même de tenter une fuite de conteneur. Le point crucial : la vulnérabilité est locale et dépend de la disponibilité du protocole SCTP sur la cible.
Le correctif a déjà été publié dans plusieurs versions stables du noyau, et l’article de référence souligne qu’un grand nombre d’environnements devraient donc être protégés après mise à jour. Voici ce que l’on sait, ce qui change pour les équipes sécurité, et comment réduire l’exposition dès maintenant.
Pourquoi la faille Linux SCTP est préoccupante
La vulnérabilité est liée au code réseau SCTP du noyau Linux. Selon les informations communiquées, elle peut être transformée en compromission complète : les tests rapportés indiquent un accès root côté hôte, puis des tentatives de sortie de l’environnement de conteneur.
Le scénario d’attaque n’est pas ouvert à tout le monde : il faut que l’attaquant soit en local et que SCTP soit joignable sur la machine visée. Cela réduit la surface d’exposition par rapport à une faille purement distante, mais ne supprime pas le risque, notamment dans des systèmes où des utilisateurs non privilégiés existent (ou peuvent atteindre le service SCTP).
Une présence de longue date : depuis 2008
Le défaut ne serait pas récent. Les chercheurs indiquent que la faille remonte à Linux 2.6.25, soit plus de dix-sept ans. Autrement dit, elle aurait traversé de nombreuses générations de noyaux.
La vulnérabilité a été suivie sous la référence CVE-2026-64564 et baptisée SCTPhantom par ses découvreurs.
Mécanisme technique : confusion d’identité et pointeur libéré
Le cœur du problème repose sur une incohérence dans la manière dont le noyau traite certaines requêtes SCTP. D’après l’explication fournie par l’avis du noyau, le système vérifie une demande de suppression (delete) en se basant sur l’adresse source du paquet, mais il agirait ensuite sur un chemin (path) sélectionné à partir d’une adresse différente contenue dans le message.
Le rapport décrit une séquence de traitement possible : un message peut inclure une adresse, puis une requête de suppression correspondant à cette adresse, et enfin une suppression « joker » (wildcard) qui libère le chemin. À la suite de cette libération, le noyau réutiliserait un pointeur désormais invalide, ce qui laisserait la connexion liée à une zone mémoire déjà libérée.
Le correctif annoncé empêche notamment qu’une suppression ciblant le chemin traité au moment de la requête soit acceptée de la manière qui déclenche le problème.
Conditions nécessaires : accès local et SCTP accessible
Le rapport insiste sur le caractère local de l’attaque. En pratique, cela signifie qu’un attaquant doit être en mesure d’exécuter un scénario exploitable sur la machine, puis d’accéder au composant SCTP.
En parallèle, la disponibilité de SCTP sur la cible joue un rôle déterminant. Les chercheurs précisent que l’exposition dépend du fait que le protocole est joignable au niveau système.
Cette contrainte réduit la probabilité d’attaque opportuniste, mais elle est particulièrement pertinente pour les environnements où des services SCTP sont exposés ou où les utilisateurs locaux peuvent déclencher des interactions réseau.
Les distributions touchées selon les tests rapportés
D’après les tests effectués par l’équipe Tencent Zhuque Lab, l’exécution du scénario a mené à un accès root sur plusieurs variantes de systèmes d’exploitation et versions de noyau testées.
Les environnements cités incluent Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 et OpenCloudOS.
Important : ces résultats sont basés sur leurs propres expériences. À la date mentionnée, aucune reproduction publique à grande échelle n’était signalée, et certains détails restent à confirmer selon les configurations exactes.
Fuite de conteneur : ce qui est revendiqué et ce qui reste incertain
Le rapport affirme que les chercheurs ont réussi à échapper à un conteneur pour atteindre la machine hôte. Toutefois, la lecture prudente des informations impose de noter plusieurs limites.
Le document ne précise pas le nom du runtime de conteneur utilisé. De plus, il indique que l’exposition peut varier fortement en fonction de facteurs comme l’accès aux sockets, les profils seccomp et les politiques liées aux espaces de noms utilisateur.
Les tests décrits mentionnent aussi un profil seccomp par défaut, sans attribution de CAP_NET_ADMIN ni CAP_SYS_ADMIN. Parmi huit tentatives, six auraient abouti à un accès root côté hôte, selon le décompte des chercheurs.
Enfin, un avis lié à openKylin n’irait pas au-delà d’un impact orienté panique noyau et déni de service, ce qui renforce l’idée que la sévérité opérationnelle peut dépendre du contexte.
Nouveaux correctifs : versions stables déjà publiées
La bonne nouvelle est que des correctifs ont déjà été intégrés dans des noyaux stables. Les versions indiquées comme contenant la correction sont :
- 7.1.6
- 6.18.42
- 6.12.101
- 6.6.148
Selon les informations de la source, ces versions ont été publiées le 3 août, ce qui arrive peu après l’identification publique de la vulnérabilité.
Si vous exécutez un noyau antérieur et que SCTP est activé ou joignable, la recommandation est claire : mettez à jour et vérifiez l’état de votre correctif via le suivi de votre distribution.
Ne vous fiez pas uniquement au numéro de version
Un point pratique souvent sous-estimé concerne les backports. Les éditeurs de distributions peuvent reprendre le correctif dans une version existante sans changer le numéro de version amont tel qu’il apparaît dans certaines interfaces.
Résultat : un simple « noyau X.Y.Z » ne suffit pas à garantir la protection. Il faut consulter le traqueur de sécurité de votre distribution pour confirmer que le correctif pour la faille Linux SCTP a bien été appliqué.
Second bug dans le même code : déjà corrigé
La source mentionne l’existence d’un second défaut du même type (toujours un use-after-free portant sur un transport) corrigé le 6 août, après la publication des noyaux stables du 3 août.
En conséquence, les versions stables citées précédemment ne protègent pas forcément contre ce second volet selon les dates exactes et l’assemblage des correctifs. Là encore, le suivi distributionnel reste l’élément le plus fiable.
Réduire l’exposition si vous n’utilisez pas SCTP
Si votre infrastructure n’a pas besoin de SCTP, une mesure de réduction du risque consiste à désactiver le module correspondant. Le raisonnement est simple : moins SCTP est disponible, moins vous laissez une porte d’entrée potentielle.
Cette approche ne remplace pas une mise à jour du noyau, mais elle réduit la surface d’attaque lorsque SCTP n’est pas requis.
Contexte de découverte : un pipeline multi-agents
Dans le rapport de référence, les chercheurs attribuent la découverte à Corvus AI, un pipeline de recherche multi-agents conçu pour des travaux sur le noyau. La vulnérabilité SCTPhantom serait la dernière d’une série de failles dormantes révélées avec assistance machine cette année.
La source cite aussi, dans la même période, d’autres vulnérabilités de noyau auparavant peu visibles. L’important pour les équipes sécurité : ces découvertes illustrent que même des composants « historiques » peuvent redevenir exploitables avec de nouveaux outils d’analyse.
Ce que vous pouvez faire maintenant
Pour agir vite, combinez mise à jour et validation :
- Mettez à jour le noyau vers une version stable incluant le correctif.
- Vérifiez via votre distribution que les backports couvrent bien CVE-2026-64564.
- Contrôlez l’exposition SCTP : si le protocole n’est pas nécessaire, désactivez le module.
- Revuez vos protections conteneurs (seccomp, permissions, politiques user-namespace), car elles peuvent influencer le résultat d’une exploitation.
Avec la faille Linux SCTP, le risque ne dépend pas uniquement du noyau : il dépend aussi de la façon dont votre système expose SCTP et de la configuration des environnements d’exécution.
Conclusion
La faille Linux SCTP suivie sous CVE-2026-64564 et nommée SCTPhantom montre comment un défaut ancien peut redevenir critique. Parce qu’elle est locale et conditionnée à l’accessibilité SCTP, elle n’est pas automatiquement « exploitable à distance », mais les impacts potentiels incluent un root hôte et des tentatives de fuite de conteneur.
La correction est déjà disponible dans des noyaux stables récents. La meilleure étape pour réduire le risque consiste à mettre à jour, puis à confirmer le correctif via le suivi de votre distribution et, si SCTP n’est pas indispensable, à réduire la surface d’attaque en désactivant le composant.
Source: https://thehackernews.com/2026/08/18-year-old-linux-sctp-flaw-could-let.html
