Un exploit a été rendu public pour GRO Frag — une vulnérabilité locale d'élévation de privilèges dans le noyau Linux, liée à la gestion de GRO et des skb zero-copy dans la pile réseau. La date précise de la découverte initiale dans les documents publics n'est pas indiquée. D'après les traces publiées, deux dates peuvent être retenues : le correctif a été discuté dans la liste de diffusion netdev 20 mai 2026, où cette vulnérabilité était déjà décrite comme capable de réécrire le cache de pages, et un PoC public a été publié sur GitHub Gist 22 mai 2026.
En mesure temporaire jusqu'à l'installation d'un noyau corrigé, il est possible de limiter le vecteur d'attaque via sysctl : kernel.io_uring_disabled=1. Ce mode interdit la création de nouvelles instances d'io_uring par des processus non privilégiés, sauf s'ils sont inclus dans le groupe autorisé io_uring_group ; avec la valeur -1, l'accès est réservé aux processus ayant CAP_SYS_ADMIN. Il s'agit plutôt d'une mitigation que d'un correctif complet de la vulnérabilité.
Le problème se situe dans la fonction skb_gro_receive() : lors de la fusion des paquets GRO, le noyau pouvait déplacer des fragments de skb zero-copy vers un autre skb sans vérifier correctement l'état de zero-copy et l'indicateur SKBFL_MANAGED_FRAG_REFS. En conséquence, les pages mémoire dont l'skb d'origine ne gardait pas de références séparées pouvaient être libérées de manière incorrecte, entraînant un use-after-free. Le patch indique clairement que cette situation peut mener à un UAF, et que la variante trouvée était capable de réécrire le cache de pages.
Le PoC publié décrit la vulnérabilité comme LPE via GRO managed-frag UAF en utilisant io_uring SEND_ZC et l'interface réseau virtuelle veth. Dans le commentaire du code, il est indiqué que les noyaux concernés sont Linux 6.0+, l'exploitation est possible par un utilisateur non privilégié, mais nécessite que io_uring soit accessible ; le correctif mentionné est commit 4db79a322db8 avec le changement « net : gro : ne pas fusionner les skbs zcopy ».
En termes de conséquences, GRO Frag se range dans la même classe d'erreurs dangereuses que Copy Fail et Dirty Frag : un attaquant disposant d'un accès local non privilégié peut modifier des données dans le cache de pages, c'est-à-dire en mémoire, sans modification obligatoire du fichier sur le disque. De telles erreurs sont particulièrement désagréables car elles affectent la frontière entre le fichier « en lecture seule » et le contenu réel que le noyau et les processus voient lors des accès ultérieurs. Elastic a auparavant décrit cette classe comme un chemin pratique pour obtenir un accès root via la corruption du cache de pages.
Au moment de la publication, aucun identifiant CVE distinct n'avait encore été attribué à GRO Frag, selon les informations disponibles. En attendant, les administrateurs devraient envisager de mettre à jour le noyau vers une version avec correctif, ainsi que d'adopter des mesures générales de réduction des risques pour de telles LPE : limiter les espaces de noms utilisateurs non privilégiés là où cela est possible, contrôler l'utilisation de io_uring et surveiller les chaînes suspectes liées à l'escalade de privilèges locale. Pour les attaques similaires Copy Fail/DirtyFrag, Elastic recommande également de combiner le patching avec la détection des primitives d'exploitation à faible niveau de la vulnérabilité.
Les primitives d'exploitation à faible niveau ne représentent pas le « hack prêt à l'emploi », mais les techniques techniques fondamentales à partir desquelles un exploit est construit.
Dans le contexte de GRO Frag, cela peut signifier ne pas détecter le fait que « l'utilisateur est devenu root », mais plutôt tenter de remarquer des actions suspectes distinctes que l'exploit utilise pour accéder à des privilèges élevés.
Source : linux.org.ru
