Une nouvelle alerte de sécurité vise les systèmes utilisant Open vSwitch sur le noyau Linux. Dénommée OVSwrap Open vSwitch, la vulnérabilité CVE-2026-64531 expose, sur un ensemble de distributions par défaut, un chemin permettant à des utilisateurs locaux d’atteindre des privilèges de niveau root. Le point clé : la faiblesse se situe dans le datapath du noyau, pas dans le démon utilisateur ovs-vswitchd.
Le correctif a été intégré aux arbres stables en fin juillet. En attendant que votre noyau fournisseur soit corrigé, plusieurs actions de mitigation peuvent réduire fortement le risque. Voici ce qu’il faut comprendre, comment la faille fonctionne et quelles mesures appliquer.
Ce que provoque la faille OVSwrap Open vSwitch
La vulnérabilité CVE-2026-64531 a reçu un score CVSS de 7,8. Elle repose sur une corruption de mémoire dans le chemin de traitement (datapath) d’Open vSwitch. Selon les détails techniques publiés par le chercheur Asim Manizada, l’attaque ne dépend pas d’un pont OVS existant et ne nécessite pas que ovs-vswitchd soit déjà en cours d’exécution.
L’exploitation s’appuie sur un scénario où le datapath du module kernel Open vSwitch est disponible et où les user namespaces non privilégiés sont activés. Dans ces conditions, un utilisateur “ordinaire” peut créer des espaces de noms privés, obtenir temporairement le CAP_NET_ADMIN à l’intérieur de cet environnement, puis emprunter la voie vulnérable d’installation des flux.
Pourquoi l’emplacement dans le noyau compte
Un point souvent mal compris dans les vulnérabilités liées à Open vSwitch est la frontière entre espace utilisateur et noyau. Ici, la faiblesse est dans le datapath kernel, c’est-à-dire la partie du traitement implémentée au niveau du noyau Linux. Cela signifie qu’une mitigation purement applicative (par exemple ajuster uniquement ovs-vswitchd) ne suffit généralement pas.
Manizada précise aussi que, dans certains cas, le simple fait que le module soit installé mais pas chargé peut suffire à déclencher un chargement automatique via la résolution de la famille Generic Netlink. Autrement dit, un module non chargé “par défaut” ne garantit pas la sécurité.
Mécanisme : dépassement de longueur et parsing à partir de données forgées
Le cœur du problème tient à la façon dont Open vSwitch stocke des actions générées sous forme d’attributs Netlink. Le champ nla_len utilisé pour décrire ces attributs est large de 16 bits, ce qui impose une limite : un attribut imbriqué ne dépasse pas 65 535 octets. Le chercheur indique qu’un garde-fou global limitait auparavant la taille totale du flux d’actions générées, ce qui empêchait l’attribut imbriqué d’atteindre le point d’enroulement.
Un changement survenu en mars 2025 a supprimé ce garde-fou. Résultat : certaines données peuvent franchir la barrière et activer un bug de troncation plus ancien. Manizada explique que, lorsqu’un attaquant soumet une action CLONE contenant de nombreux sous-éléments liés à la table de conntrack, le noyau x86-64 peut développer chaque sous-action jusqu’à ~164 octets. À ce moment-là, le flux généré peut dépasser la taille maximale de l’attribut imbriqué.
Quand Open vSwitch écrit la longueur dans un champ de 16 bits, une valeur enroulée apparaît. Le code suivant fait alors confiance à cette longueur et reprend l’analyse au mauvais endroit dans le tampon, là où se trouvent des données contrôlées par l’attaquant. L’atterrissage étant déterministe dans le même tampon contigu, il n’est pas nécessaire de recourir à un “heap grooming” compliqué.
Chaîne d’exploitation et impact réel
Le chercheur qualifie la fiabilité du mécanisme comme relevant d’un “niveau logique” très constant. Le proof-of-concept publié exploite trois primitives découlant de l’enroulement :
- une fuite d’un pointeur noyau via une action OUTPUT fabriquée ;
- une lecture arbitraire du noyau à l’aide d’une action SET associée à un tunnel ;
- un décrément ciblé via la phase de teardown d’un pointeur tun_dst forgé.
Avec ces primitives, l’exploit peut viser les identifiants de sécurité d’un processus et, sur des noyaux récents, ramener les valeurs fsuid et fsgid à zéro. Le PoC est indiqué comme explicitement destructif : il modifie des structures en cours d’utilisation, ce qui rend l’exécution risquée sans précautions.
En plus de l’activation des user namespaces non privilégiés, le PoC nécessite aussi des composants précis : support OVS conntrack, helper FTP conntrack et la présence de sudo.
Réussite : modification de configuration, shell root et traces
En cas de succès, l’exploit corrompt une structure de crédential du noyau. Il peut ensuite modifier les fichiers de configuration de sudo (par exemple /etc/sudoers.d ou /etc/sudoers), ouvrir un shell root, puis laisser volontairement des processus et l’état d’Open vSwitch en place pour éviter des comportements dangereux lors du teardown.
Le dépôt du PoC inclut des enregistrements pour environ 800 builds exactes de noyaux x86-64. Pour les configurations non couvertes, le code tente une dérivation dynamique à partir de symboles ou de BTF quand c’est possible.
Quelles distributions sont concernées
Une matrice de test (non exhaustive) a montré que l’exploitation “tel quel” fonctionne sur plusieurs systèmes. Parmi les exemples cités : AlmaLinux 9 et 10, Alpine 3.22 à 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 et 10, Debian 12 et 13, Fedora 42 à 44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 et 10, ainsi que Ubuntu 22.04.
Pour Ubuntu 24.04, AppArmor peut empêcher la création directe d’espaces de noms. Le PoC prévoit alors un contournement via une exécution contrôlée (fonction de repli mentionnée sous la forme aa-exec -p trinity), qui rétablit l’accès. Sur Ubuntu 26.04, la route “utilisateur standard” est bloquée dans le scénario testé ; la désactivation d’une restriction AppArmor sur les user namespaces non privilégiés a permis l’exploitation dans les tests réalisés.
À l’inverse, certains systèmes testés conservent des chemins de code plus anciens et n’étaient pas exploitables via cette route : Amazon Linux 2, Debian 11, Rocky Linux 8 et Ubuntu 20.04.
Correctifs amont : versions où le risque baisse
Les correctifs amont ont été introduits dans les arbres stables à partir du 24 juillet. Les premières versions mentionnées sont : Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 et 7.1.5.
Le chercheur souligne toutefois un point important : les numéros de version seuls ne suffisent pas. Les distributions incluent souvent des backports et des changements en aval. La source la plus fiable reste donc le suivi du fournisseur (tracker de la distribution).
Par ailleurs, certaines séries proches de la fin de vie (6.13 à 6.17, 6.19 et 7.0) ne devraient pas recevoir de correctifs stables amont.
Mesures d’urgence en attendant votre noyau corrigé
Si vous n’avez pas encore un noyau corrigé via votre éditeur, priorisez une réduction du risque avant de mettre à jour. Deux axes ressortent : empêcher le chargement du module Open vSwitch et/ou fermer la route liée aux user namespaces.
1) Bloquer le chargement du module Open vSwitch
Lorsque Open vSwitch n’est pas requis, une mitigation rapide consiste à empêcher le chargement futur du module. Exemple proposé :
- créer un fichier de configuration modprobe, et y définir : install openvswitch /bin/false
Le message clé : si le module est déjà chargé, bloquer les futurs chargements ne suffit pas. Il faut alors décharger le module ou redémarrer pour revenir à un état sûr.
2) Désactiver les user namespaces non privilégiés
Désactiver les user namespaces non privilégiés ferme la route la plus directe décrite par le PoC. Le chercheur précise cependant que cela ne garantit pas l’absence de risque pour tous les scénarios : un conteneur ou un processus déjà doté de CAP_NET_ADMIN sur un namespace contrôlé par un attaquant pourrait théoriquement rester dans le périmètre.
Dans les éléments publiés, cette direction “conteneurs” est évoquée mais non démontrée via le PoC rendu public. Si vous gérez des environnements multi-utilisateurs ou multi-workloads non fiables, considérez cette limitation comme un argument supplémentaire pour appliquer les correctifs et durcir l’environnement.
3) Cas particulier : sécurité et fiabilité des environnements partagés
Le risque est particulièrement sensible lorsque plusieurs utilisateurs, des équipes internes ou des charges non fiables partagent un même hôte. Dans ce contexte, même une compromission initiale “limitée” peut être amplifiée : le problème local devient alors un incident à l’échelle de la machine, comme l’illustre la logique de l’avis mentionné.
À retenir : agir vite et vérifier côté distribution
OVSwrap Open vSwitch est une vulnérabilité du noyau Linux liée au datapath d’Open vSwitch, conçue pour aboutir à une escalade de privilèges vers root dans des conditions spécifiques. Comme l’exploit cible des mécanismes bas niveau (longueurs Netlink, parsing noyau et structures de crédentials), les mitigations applicatives seules sont insuffisantes.
La meilleure approche reste de mettre à jour vers un noyau corrigé dès que votre fournisseur publie des paquets adaptés. En attendant, bloquez le module si Open vSwitch n’est pas indispensable, et réduisez l’exposition en agissant sur les user namespaces non privilégiés. Pour décider vite, appuyez-vous sur le tracker de votre distribution plutôt que sur les seuls numéros de versions amont.
Source: https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html
