← Retour au blog
Sécurité 6 août 2026 à 15:10
Collaborer avec mon assistant IA :

OVSwrap (CVE-2026-64531) : une faille Open vSwitch peut donner root sous Linux

OVSwrap est une élévation de privilèges locale dans le datapath Open vSwitch du noyau Linux. Un exploit public permet à un utilisateur non privilégié d'obtenir root sur de nombreux noyaux vulnérables.

Illustration d'une alerte de sécurité concernant une élévation de privilèges dans le noyau Linux

Dans le cadre de notre veille sécurité, nous signalons OVSwrap, suivie sous l’identifiant CVE-2026-64531.

Cette vulnérabilité touche le datapath Open vSwitch intégré au noyau Linux. Un utilisateur local non privilégié peut provoquer un dépassement de taille dans une action réseau imbriquée, détourner l’analyse de données contrôlées en mémoire noyau et obtenir un accès root sur l’hôte.

Le score CVSS attribué par kernel.org est de 7,8 sur 10. La faille n’est pas une porte d’entrée distante, mais elle est sérieuse : un exploit public couvre déjà près de 800 builds de noyaux x86-64 et l’exploitation décrite est déterministe une fois les décalages propres au build connus.

Le chercheur Asim Manizada a signalé le problème le 19 juin 2026. Les correctifs ont rejoint les branches stables le 24 juillet, avant la publication coordonnée de l’analyse et du PoC le 28 juillet 2026.

Pourquoi OVSwrap mérite une réaction rapide

OVSwrap exige déjà une capacité d’exécution sur la machine. Elle ne permet pas, seule, à un attaquant sur Internet de devenir root.

Elle devient en revanche critique dès qu’un acteur malveillant dispose d’un point d’appui limité :

  • compte utilisateur compromis ;
  • shell obtenu via une application vulnérable ;
  • job CI/CD exécutant du code non fiable ;
  • serveur ou poste partagé entre plusieurs utilisateurs ;
  • conteneur doté de CAP_NET_ADMIN sur un espace réseau qu’il contrôle ;
  • processus de gestion réseau déjà compromis.

Le chemin le plus simple passe par la création d’espaces de noms utilisateur et réseau non privilégiés. L’utilisateur y obtient CAP_NET_ADMIN pour son espace réseau privé, crée un datapath OVS et atteint le code vulnérable sans posséder cette capacité sur l’hôte.

Un bridge Open vSwitch existant, un service ovs-vswitchd actif ou CAP_NET_ADMIN dans l’espace de noms initial ne sont pas obligatoires. Lorsque le module openvswitch est installé et chargeable, la résolution de la famille Generic Netlink correspondante peut provoquer son chargement automatique.

Ce qui casse dans Open vSwitch

Open vSwitch reçoit depuis l’espace utilisateur des règles de flux et des listes d’actions : transmettre un paquet, modifier des champs, appliquer le suivi de connexion, cloner le paquet ou exécuter une autre liste d’actions.

Le noyau valide ces actions et convertit certaines d’entre elles vers une représentation interne plus volumineuse. Elles sont stockées sous forme d’attributs Netlink dont le champ de longueur, nla_len, ne fait que 16 bits. Une action imbriquée individuelle ne peut donc pas dépasser 65 535 octets.

Avant le correctif, cette limite n’était pas contrôlée au moment de fermer une action générée. Une action CLONE contenant des centaines de petites sous-actions conntrack pouvait être développée par le noyau au-delà de 64 Kio. La longueur réelle était alors tronquée lors de son enregistrement dans nla_len.

La séquence d’exploitation devient la suivante :

  1. l’attaquant soumet une liste d’actions valide mais conçue pour grossir lors de sa conversion ;
  2. l’action imbriquée dépasse 65 535 octets et sa longueur 16 bits revient à une petite valeur ;
  3. lors d’une lecture ou de la suppression du flux, le noyau fait confiance à cette longueur tronquée ;
  4. l’analyse reprend au milieu de données conntrack contrôlées par l’attaquant ;
  5. ces octets sont interprétés comme de nouvelles actions OVS ;
  6. le PoC transforme cette confusion en lecture mémoire puis en décrément contrôlé de données d’identification ;
  7. les identifiants effectifs du processus sont ramenés à zéro, ce qui permet d’agir comme root.

Le correctif conserve la possibilité d’avoir un flux total d’actions supérieur à 64 Kio, mais refuse toute action imbriquée dont la taille ne tient pas dans nla_len. Il nettoie aussi correctement les ressources déjà allouées lorsque la construction échoue.

Ce qui est impacté

La faille est atteignable lorsque les conditions suivantes sont réunies :

  • le noyau contient le changement de mars 2025 qui a supprimé l’ancienne limite interne de 32 Kio, mais pas le correctif OVSwrap ;
  • le datapath Open vSwitch du noyau est disponible ou chargeable ;
  • l’attaquant peut exécuter du code localement ;
  • il peut créer des espaces de noms non privilégiés, ou possède déjà CAP_NET_ADMIN sur un espace réseau contrôlé.

Pour les noyaux stables amont, les plages annoncées sont :

Branche Versions affectées Première version corrigée
5.15.y 5.15.180 à 5.15.211 5.15.212
6.1.y 6.1.132 à 6.1.177 6.1.178
6.6.y 6.6.84 à 6.6.144 6.6.145
6.12.y 6.12.20 à 6.12.96 6.12.97
6.13.y 6.13.8 à 6.13.12 Branche en fin de vie
6.14.y à 6.17.y Toutes les versions Branches en fin de vie
6.18.y 6.18.0 à 6.18.39 6.18.40
6.19.y et 7.0.y Toutes les versions Branches en fin de vie
7.1.y 7.1.0 à 7.1.4 7.1.5

Ces numéros ne suffisent pas pour conclure sur un noyau de distribution. RHEL, Debian, Ubuntu, SUSE et leurs dérivées rétroportent des changements et correctifs sans nécessairement reprendre la version amont complète.

Les tests publiés couvrent notamment Debian 12 et 13, Ubuntu 22.04 et 24.04, AlmaLinux 9 et 10, Rocky Linux 9 et 10, CentOS Stream 9 et 10, Amazon Linux 2023, Alpine, Arch Linux, Fedora, Linux Mint, NixOS, openSUSE Tumbleweed et Pop!_OS. Cette liste est un échantillon, pas un inventaire exhaustif.

À l’inverse, un ancien numéro de noyau ne signifie pas automatiquement que le système est vulnérable. Rocky Linux 8 et CentOS 7, par exemple, précèdent le changement qui a rendu le dépassement exploitable. Certaines branches SUSE ont également conservé l’ancienne limite.

Conteneurs, virtualisation et cloud : le noyau hôte reste la frontière

Open vSwitch est courant dans les plateformes de virtualisation, les clouds privés, les infrastructures SDN et certains environnements de conteneurs. Ce contexte augmente l’intérêt opérationnel d’OVSwrap, sans rendre pour autant tous ces systèmes vulnérables par défaut.

Un processus de conteneur disposant de CAP_NET_ADMIN sur un espace réseau qu’il contrôle peut atteindre la corruption du noyau hôte sans passer par les espaces de noms utilisateur non privilégiés. Le PoC public ne met pas en œuvre cette voie, mais le chercheur la considère techniquement atteignable.

Mettre à jour une image de conteneur ne corrige donc rien ici. La vulnérabilité se trouve dans le noyau de l’hôte : les workers Kubernetes, hyperviseurs et nœuds réseau concernés doivent recevoir un noyau corrigé puis redémarrer.

Le datapath OVS entièrement en espace utilisateur, notamment avec DPDK, n’emprunte pas le module vulnérable. Il faut néanmoins vérifier le datapath réellement utilisé avant de classer un hôte hors périmètre.

Vérifier l’exposition sans exécuter le PoC

Le PoC public modifie des données d’identification dans le noyau afin d’obtenir root. Il ne doit pas devenir une commande de contrôle sur une machine de production.

Commencez par relever le noyau réellement chargé :

uname -r

Vérifiez si le module Open vSwitch est déjà actif :

lsmod | grep '^openvswitch\b' || true

Vérifiez ensuite s’il est disponible, même lorsqu’il n’est pas encore chargé :

modinfo openvswitch 2>/dev/null | sed -n '1,12p'

Contrôlez les principaux réglages liés aux espaces de noms non privilégiés :

sysctl kernel.unprivileged_userns_clone user.max_user_namespaces user.max_net_namespaces 2>/dev/null || true

Enfin, recherchez les usages OVS réels sur l’hôte :

systemctl is-active openvswitch ovs-vswitchd 2>/dev/null || true

Ces vérifications qualifient la surface d’attaque, mais seule la comparaison du paquet noyau avec l’avis de sécurité de la distribution permet de confirmer la présence du correctif. L’absence du module dans lsmod n’est pas une preuve suffisante s’il reste installé et autochargeable.

Mitigations temporaires

Bloquer le module si Open vSwitch n’est pas utilisé

Si l’inventaire confirme qu’Open vSwitch n’est nécessaire à aucun service, empêcher le chargement du module est la mesure compensatoire la plus ciblée :

printf 'install openvswitch /bin/false\n' > /etc/modprobe.d/ovswrap.conf

Un redémarrage permet ensuite de repartir sans copie du module déjà résidente. Décharger openvswitch à chaud peut interrompre les réseaux virtuels, OVN, des bridges ou des workloads en production ; cette opération exige donc une qualification et une fenêtre de maintenance.

Cette mitigation ne convient pas aux hôtes qui dépendent du datapath OVS du noyau.

Restreindre les espaces de noms non privilégiés

Désactiver la création d’espaces de noms réseau ou utilisateur non privilégiés peut bloquer le chemin d’exploitation d’un compte local ordinaire. Cette mesure peut toutefois casser des conteneurs rootless, des sandboxes, des navigateurs, des postes développeurs ou des jobs CI.

Elle n’arrête pas un processus ou un conteneur qui dispose déjà de CAP_NET_ADMIN sur un espace réseau contrôlé. Ce n’est donc pas une protection complète dans les environnements conteneurisés.

Le chercheur publie aussi un garde BPF d’urgence avec son PoC. Son déploiement dépend du build du noyau et doit être considéré comme une mesure temporaire à tester, pas comme un remplacement du correctif.

Remédiation : noyau corrigé et redémarrage

La réponse durable consiste à installer le noyau corrigé fourni par la distribution puis à démarrer effectivement dessus.

La séquence opérationnelle recommandée est la suivante :

  1. inventorier les hôtes où le module openvswitch est présent ou intégré ;
  2. identifier les usages OVS, OVN, SDN, cloud et virtualisation ;
  3. prioriser les machines multi-utilisateurs, les runners CI et les conteneurs avec CAP_NET_ADMIN ;
  4. comparer le noyau chargé au bulletin de la distribution ;
  5. appliquer une mitigation compatible si la maintenance doit attendre ;
  6. installer le paquet noyau corrigé ;
  7. redémarrer complètement la machine ;
  8. contrôler la version chargée et conserver la preuve de remédiation.

Après le redémarrage :

uname -r

La simple présence d’un paquet corrigé sur disque ne protège pas l’hôte tant que l’ancien noyau reste en mémoire. Pour les branches amont en fin de vie, il faut migrer vers une branche maintenue ou utiliser le noyau corrigé explicitement fourni par l’éditeur.

Si une exploitation est suspectée

OVSwrap altère la mémoire du noyau et les identifiants d’un processus. Un échec d’exploitation peut aussi provoquer un crash ; l’absence de crash ou de message évident dans dmesg n’exclut donc pas une compromission réussie.

Sur un hôte vulnérable ayant exécuté du code non fiable :

  • recherchez les créations ou modifications inhabituelles dans /etc/sudoers et /etc/sudoers.d ;
  • examinez les comptes, clés SSH, services, tâches planifiées et binaires SUID ;
  • corrélez les journaux d’authentification avec les événements OVS et noyau ;
  • faites tourner les secrets accessibles depuis la machine ;
  • considérez une reconstruction maîtrisée si l’intégrité du noyau et du système ne peut plus être établie.

Patcher et redémarrer ferme la vulnérabilité, mais n’efface pas une persistance installée avant la maintenance.

Notre lecture opérationnelle

OVSwrap est locale, mais son périmètre est plus large que la seule présence d’un service Open vSwitch actif. L’autochargement du module, les espaces de noms non privilégiés et les capacités accordées aux conteneurs doivent entrer dans l’inventaire.

La priorité ne se décide donc pas avec un seul lsmod. Elle repose sur plusieurs informations :

  • noyau réellement chargé et politique de rétroportage de la distribution ;
  • disponibilité du module Open vSwitch ;
  • dépendance réelle à OVS ou OVN ;
  • droits de création d’espaces de noms ;
  • conteneurs possédant CAP_NET_ADMIN ;
  • exposition à du code local non fiable ;
  • redémarrage effectivement réalisé après mise à jour.

Cette démarche est celle d’une veille CVE quotidienne reliée à l’exploitation : transformer une alerte technique en périmètre, priorité, changement contrôlé et preuve de correction.

Chez Forget About IT, ce type d’alerte entre dans le maintien en condition de sécurité : qualification du parc, préparation du correctif, continuité des réseaux virtuels, redémarrage contrôlé et vérification après intervention.

Conclusion

OVSwrap (CVE-2026-64531) est une élévation de privilèges locale sérieuse dans Open vSwitch. Sur un noyau vulnérable, un utilisateur non privilégié peut atteindre le datapath via ses propres espaces de noms, corrompre la mémoire noyau et obtenir root. Un conteneur doté de CAP_NET_ADMIN peut également exposer le noyau hôte.

Le bon réflexe :

  • ne pas limiter le contrôle aux services OVS déjà actifs ;
  • vérifier si le module est installé et autochargeable ;
  • qualifier les espaces de noms et capacités des conteneurs ;
  • bloquer le module seulement s’il est réellement inutile ;
  • installer le noyau corrigé fourni par la distribution ;
  • redémarrer puis vérifier la version réellement chargée.

Si vous avez besoin d’aide pour qualifier l’exposition ou organiser la remédiation sur votre parc Linux, nous pouvons vous accompagner dans le cadre de notre infogérance.

Sources

Articles recommandés