Le problème en deux phrases
La ciblesnat d’ebtables, le pare-feu des ponts réseau Linux, peut réécrire l’adresse matérielle de l’expéditeur dans les paquets ARP. Le module ebt_snat effectue cette écriture via skb_store_bits() sans vérifier au préalable que la zone mémoire visée est modifiable.
Quand cette zone est une page de fichier importée par splice(), le noyau écrit directement dans le cache de pages. La NVD classe la faille en écriture hors limites (CWE-787), avec un score CVSS de 8,8.
Pourquoi celle-ci compte
Sur le papier, la faille exige une configuration rare : une règle ebtables SNAT avec réécriture ARP (--snat-arp) sur un pont. Red Hat la décrit d’ailleurs comme dépendante de « configurations netfilter de pont spécifiques ». C’est vrai, mais incomplet.
L’attaquant peut créer lui-même cette configuration. Il lui faut la capacité CAP_NET_ADMIN dans l’espace de noms réseau qui porte le pont. Là où les espaces de noms utilisateur non privilégiés sont autorisés, un simple compte l’obtient avec unshare -Urn, dans son propre espace de noms, sans rien toucher à la configuration de l’hôte.
Le module se charge tout seul. ebt_snat est chargé automatiquement dès qu’une règle le réclame. Qu’il soit absent de lsmod aujourd’hui ne vous protège pas.
L’écriture vise le cache de pages. Six octets contrôlés écrits dans une page de fichier suffisent à modifier en mémoire un fichier lisible mais non modifiable par l’attaquant, un binaire setuid par exemple.
Ces trois points viennent du suivi public de la faille, pas des avis des distributions, qui ne détaillent pas le chemin d’attaque. La CISA ne dit pas non plus comment l’exploitation qu’elle a constatée a été menée.
Évaluer son exposition
La question est double : qui peut exécuter du code sur la machine, et peut-il obtenirCAP_NET_ADMIN ?
Comme toujours avec ce type de faille, il faut un point d’appui local. Elle n’est pas exploitable à distance en elle-même, mais transforme une application web compromise ou un compte peu privilégié en contrôle de la machine.
Pour savoir si un compte non privilégié peut créer son propre espace de noms réseau :
Appliquer le correctif
Le correctif amont a été intégré à Linux 7.1-rc7. Il rend la zone de l’adresse ARP modifiable avant de la lire puis de la réécrire.Debian, Ubuntu et dérivées
AlmaLinux, Rocky Linux et RHEL
Red Hat publie aussi
kernel-rt-4.18.0-553.143.1.rt7.484.el8_10 pour le noyau temps réel de RHEL 8 (RHSA-2026:39082). Toute version ultérieure à celles du tableau contient le correctif.
Mitigation immédiate
À appliquer si votre noyau corrigé n’est pas encore disponible, ou tant que vous n’avez pas pu redémarrer.Bloquer le module ebt_snat
Sans le module, la cible SNAT d’ebtables n’existe plus, et le chemin vulnérable avec elle.
Si vous administrez un hôte qui s’appuie sur des règles ebtables SNAT, ce blocage les casse. Red Hat propose dans ce cas une autre voie : retirer l’option de réécriture ARP de ces règles, ou supprimer les règles SNAT qui portent sur le trafic ARP. Listez-les avec
sudo ebtables -t nat -L.Couper les espaces de noms utilisateur non privilégiés (Debian et Ubuntu)
Deuxième barrière : empêcher un compte ordinaire d’obtenirCAP_NET_ADMIN dans son propre espace de noms. Ce paramètre existe sur les noyaux Debian et Ubuntu.
Sur un cluster Kubernetes
Propagez le blocage du module sur tous les nœuds avec un DaemonSet privilégié. Le conteneurpause évite que le DaemonSet redémarre en boucle après l’initContainer.