Linux : la faille IPv4 ne se limite pas aux serveurs MPTCP

Une connexion TCP ordinaire entre aussi dans le périmètre

Le défaut est une utilisation de mémoire après sa libération dans le traitement des options IPv4 du noyau. Deux opérations concurrentes peuvent encore lire des options déjà libérées, notamment lors de certaines retransmissions de demandes de connexion ou migrations de sockets. La fiche NVD confirme ce mécanisme ; elle n’a pas encore de configuration CPE permettant de classer toutes les distributions.

Le bulletin Red Hat vise les systèmes avec un noyau vulnérable et IPv4 TCP activé, surtout ceux qui acceptent des connexions entrantes. Il n’exige pas un compte ni une interaction du lecteur, même si une exécution de code fiable demande un contrôle précis de la course mémoire. Ne déclarez donc pas un serveur hors de portée uniquement parce que MPTCP est désactivé. Red Hat précise que MPTCP est désactivé par défaut dans RHEL et qu’une liste vide d’écoutes MPTCP ne constitue pas un test d’absence d’exposition.

Choisir la ligne du paquet, pas un numéro Linux universel

Au contrôle du 3 novembre, le suivi Debian indique linux 6.1.190-1 corrigé pour bookworm. Pour trixie, il donne 6.12.113-1 comme première version corrigée et affiche désormais 6.12.115-2 dans le dépôt de sécurité. Le paquet source linux-6.12 de bookworm a sa propre ligne, 6.12.113-1~deb12u1. Ces numéros ne se transposent pas à Ubuntu ou à Red Hat.

Au contrôle du 3 novembre, la fiche CVE Ubuntu marque encore linux vulnérable sur 22.04, 24.04, 26.04 et 26.10, avec un travail en cours. Son article technique précise que les correctifs de 22.04, 24.04 et 26.04 sont disponibles dans -proposed pour les utilisateurs capables d’exécuter leurs propres tests d’acceptation du noyau. Pour 24.04, le repère est 6.8.0-149.149. Ce dépôt de qualification ne doit pas être confondu avec une diffusion générale dans les mises à jour.

Les deux pages Ubuntu divergent pour 26.10 : l’article donne 7.3.0-10.10 comme corrigé, alors que la fiche CVE affiche encore ce même numéro en préparation. Nous conservons ces deux états attribués au lieu de déclarer la branche corrigée sur cette seule lecture. Faites confirmer le paquet disponible et le noyau actif par votre mainteneur. Les variantes HWE et cloud restent à vérifier sur leurs propres lignes.

La fiche Ubuntu relue le 5 novembre ajoute des repères en préparation pour plusieurs noyaux spécialisés : linux-nvidia sur 26.04 vise 7.0.0-1025.26, linux-nvidia-7.0 sur 24.04 vise 7.0.0-1025.26~24.04.1 et linux-nvidia-bos sur 26.04 vise 7.0.0-2024.25. Ces lignes restent marquées vulnérables avec travail en cours. Un numéro de paquet annoncé ne prouve donc pas sa disponibilité dans vos dépôts ni son activation sur la machine.

Red Hat cite RHEL 8, 9, 10 et OpenShift, ainsi que les produits dépendant de ces noyaux, et dit accélérer les correctifs. Le bulletin lu ne fournit pas de version corrigée universelle. Faites confirmer l’erratum et le paquet propres à votre système.

Un filtrage provisoire demande aussi un contrôle d’exploitation

Red Hat documente un filtrage nftables des paquets IPv4 TCP contenant des options IP. Il dit que cette mesure réduit l’exposition sans la supprimer complètement et qu’elle peut perturber des usages nécessaires. Les options IP ne sont pas les options TCP ordinaires : ne remplacez pas la règle par un blocage improvisé de tout le trafic TCP. La règle Red Hat n’est pas persistante : elle ne survit pas au redémarrage. Si elle est retenue pendant l’attente du correctif, son maintien doit donc être vérifié après chaque redémarrage.

La fiche Ubuntu révisée le 3 novembre décrit à son tour ce filtrage, avec des conditions précises : nftables, droits administrateur et absence de besoin d’options IPv4. Sa recette de persistance suppose que nftables gère le pare-feu sans UFW ni firewalld. Elle couvre l’hôte, y compris ses connexions vers lui-même ; les conteneurs ayant leur propre réseau demandent une règle séparée. IPv6 et les options TCP ordinaires restent hors de ce blocage. Ubuntu conserve aussi la limite : le filtrage réduit le risque sans empêcher entièrement l’exploitation.

L’article technique Ubuntu juge pour sa part que les mises à jour de sécurité sont la seule atténuation appropriée et rappelle que désactiver MPTCP ne traite pas ce défaut général. Ce conseil est plus strict que la recette de filtrage conservée dans sa fiche CVE. Ne prenez pas cette recette pour une validation universelle de la protection du serveur.

Red Hat publie maintenant une consigne pour OpenShift Container Platform 4, fondée sur des règles nftables distribuées aux nœuds par des ressources MachineConfig et des politiques de perturbation des nœuds. Son périmètre reste le trafic externe : une règle sur le nœud ne filtre que son espace réseau hôte, pas le trafic entre pods dans le réseau OVN-Kubernetes. Le filtrage du trafic externe transféré aux pods dépend aussi de la configuration réseau. Le bulletin ne propose pas encore d’atténuation du trafic entre pods et signale qu’appliquer des règles dans chaque espace réseau de pod serait intrusif et créerait une course lors de leur création ou déplacement. Les mises à jour de sécurité du noyau restent la seule solution complète indiquée. Ne présentez donc pas une règle réussie sur l’hôte comme une protection de tout le cluster.

Faites évaluer cette atténuation par le responsable réseau dans un environnement de test, avec un accès de secours et un retour arrière. Le bulletin demande de retirer la règle après passage à un noyau corrigé. Ce n’est ni une preuve d’invulnérabilité ni un remplacement durable du correctif.

Après installation, vérifier le noyau qui tourne

Relevez la distribution, sa branche, le paquet de noyau et les services exposés. Après la mise à jour prévue par son éditeur, vérifiez que le noyau actif est bien celui attendu et que les accès utiles fonctionnent. Planifiez le redémarrage nécessaire sans perdre votre seul accès d’administration.

Les sources primaires lues décrivent une vulnérabilité et des remédiations, pas un examen de votre serveur. Nous n’avons exécuté ni exploit ni règle de filtrage. Cette brève ne reprend pas comme fait primaire une exploitation active, un temps de démonstration ou un réglage par défaut de Go rapportés ailleurs.

• Prévoir les mises à jour et la restauration du serveur↗