Cybersécurité
Faille TCP du noyau Linux : vos serveurs vidéo, NVR et passerelles sont aussi concernés
Il y a des failles qui ne touchent « que » les serveurs informatiques. Et puis il y a celles du noyau Linux, le cœur d’une bonne partie de ce que nous installons dans les locaux techniques : serveurs de vidéoprotection, enregistreurs, passerelles GTB, NAS, supervisions. CVE-2026-98432 est de celles-là, et près d’un mois après le correctif amont, deux grandes distributions n’avaient toujours pas de noyau corrigé au 1er novembre.
Les faits
- La faille : une condition de course dans le code TCP IPv4 du noyau, au moment où une connexion s’établit. Le noyau peut alors relire une mémoire déjà libérée (use-after-free). Le déclencheur documenté : une demande de connexion portant des options IP (Record Route ou Timestamp), envoyée puis renvoyée pour gagner la course.
- L’ancienneté : le bug est présent depuis Linux 4.4. Le correctif amont date du 5 octobre, la CVE du 15 octobre.
- La gravité : 9,8 sur 10 pour l’équipe CVE du noyau, 8,1 chez Red Hat, SUSE et Oracle, 7,0 chez Amazon. L’écart tient à l’appréciation des conditions d’exploitation.
- L’exploit : Anthropic a publié le 27 octobre les travaux d’un de ses modèles d’IA non diffusé, qui a obtenu un accès root à distance en 53 minutes environ, sur un serveur exposant un service MPTCP. Aucune attaque réelle n’était signalée au 29 octobre.
- Ce qui n’est pas concerné : IPv6, où le noyau traite les options autrement.
Où en sont les correctifs au 1er novembre
| Système | État |
|---|---|
| Noyau amont | Corrigé à partir de 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3 |
| Branches 4.4 à 5.4 (fin de vie) | Aucun correctif |
| Debian 12 et 13 | Corrigés |
| SUSE (SLES 16, SLES 15 SP4 à SP6), Oracle UEK, Amazon Linux | Corrigés |
| Ubuntu 22.04 à 26.10 | Correctif en préparation, pas encore publié |
| Ubuntu 20.04 et antérieurs | Pas de correctif |
| RHEL 8, 9 et 10 | Pas de correctif ; AlmaLinux en dépôt de test |
Pourquoi un intégrateur sûreté doit s’en soucier
Dans nos métiers, Linux est partout, souvent sans qu’on le voie : le serveur VMS installé sur une distribution d’entreprise, l’enregistreur vidéo, la caméra elle-même, la passerelle BACnet ou LoRaWAN, le NAS de sauvegarde, la supervision GTB. Et beaucoup d’équipements embarqués tournent sur des noyaux anciens, parfois de la branche 4.x, que plus personne ne corrige en amont.
Sur un serveur que vous administrez, la réponse est classique : noyau corrigé de la distribution, puis redémarrage. Sur un équipement embarqué, vous ne pouvez rien faire vous-même : seul le constructeur peut livrer un firmware avec un noyau corrigé. Et c’est là que les délais risquent de s’allonger.
Ce que je ferais cette semaine
- Inventorier ce qui tourne sous Linux sur chaque site : les serveurs (avec
uname -ret la distribution exacte), mais aussi les enregistreurs, passerelles et NAS. - Vérifier l’exposition : la faille vise un service TCP joignable. Un enregistreur publié sur Internet par une redirection de port est le pire scénario ; un équipement dans un VLAN technique filtré l’est beaucoup moins.
- Mettre à jour les serveurs dont la distribution est corrigée, et planifier le redémarrage avec l’exploitant : un serveur VMS qui redémarre, ce sont quelques minutes d’enregistrement à surveiller.
- En attendant les autres (Ubuntu, RHEL et dérivés) : désactiver MPTCP s’il ne sert à rien (
net.mptcp.enabled=0), ou rejeter avec nftables les paquets TCP IPv4 porteurs d’options IP. Selon Red Hat, ce filtrage réduit l’exposition sans l’éliminer, et il se teste avant de partir en production. - Interroger les constructeurs de vos équipements embarqués : version du noyau, exposition, date du firmware corrigé. Et noter ceux qui répondent vite 🙂
Mon avis
Ce qui me fait tiquer, ce n’est pas tant la faille, des bugs du noyau il y en a régulièrement, que le décalage : correctif amont le 5 octobre, et presque un mois plus tard deux distributions majeures sans noyau publié. Pour nos équipements embarqués, ce sera forcément plus long, et certains matériels restés sur des branches en fin de vie ne seront peut-être jamais corrigés. C’est un argument de plus pour demander, dès l’appel d’offres, la durée de support logiciel d’un équipement.
L’autre leçon, c’est la vitesse : un modèle d’IA a transformé un bug de course en prise de contrôle à distance en moins d’une heure. Que l’on s’en réjouisse pour la défense ou que l’on s’en inquiète, le résultat est le même pour nous : le délai entre la publication d’un correctif et son exploitation se raccourcit. La segmentation des réseaux techniques et l’absence d’exposition directe sur Internet restent la meilleure assurance, bien avant le correctif lui-même.
Commentaires
Aucun commentaire pour l'instant : lancez la discussion.