Une nouvelle vulnérabilité de privilèges locaux a été révélée dans le noyau Linux, intitulée Fragnesia et identifiant CVE-2026-46300. Le problème appartient à la même catégorie d'attaques sur le cache de page que les récemment discutées Copy Fail et Dirty Frag, mais ce n'est pas une réédition d'une ancienne erreur : il s'agit d'un défaut distinct dans le code. XFRM ESP-in-TCP.
La vulnérabilité a été découverte par le chercheur William Bowling de l'équipe V12 Security. Selon la description publiée, Fragnesia permet à un utilisateur local non privilégié de modifier le contenu des fichiers, accessibles en lecture seule, dans la mémoire du cache de page, et grâce à cela, d'exécuter du code avec des droits root. Contrairement à de nombreux anciens exploits LPE, l'attaque ne nécessite pas de condition de course et est décrite par les chercheurs comme déterministe.
Techniquement, le problème est lié au fait que lors de la fusion des tampons réseau, le noyau pouvait perdre l'indication que le fragment de données était « partagé » et lié à une page de mémoire externe, y compris au cache de page. Dans le patch proposé, cela est décrit comme une erreur dans skb_try_coalesce() : lors du transfert des fragments paginés d'un sk_buff à un autre, le drapeau SKBFL_SHARED_FRAG n'était pas conservé. Par conséquent, un code ultérieur d'ESP pouvait à tort considérer le tampon comme sûr à modifier.
L'effet pratique est que les données précédemment mises dans la file TCP à partir d'un fichier, après le passage du socket en mode espintcp, pouvaient être traitées par le noyau comme un texte chiffré ESP. Lors de la déchiffrement AES-GCM, les octets étaient modifiés directement dans la page du cache de page liée au fichier. Cela ne modifie pas le fichier sur le disque, mais change sa représentation en mémoire jusqu'à ce que la page soit expulsée du cache.
Dans la démonstration d'attaque publiée, l'objectif utilisé était /usr/bin/su : l'exploit modifiait les premiers octets du fichier binaire dans le cache de page et lançait ensuite la copie modifiée en mémoire, obtenant un shell avec des droits root. Le fichier source sur le disque restait inchangé, ce qui rend le problème particulièrement difficile à diagnostiquer : les traces d'exploitation peuvent disparaître après le nettoyage du cache de page ou le redémarrage.
Fragnesia est apparue moins d'une semaine après Dirty Frag. La V12 souligne qu'il s'agit d'une vulnérabilité distincte dans la même surface d'attaque — ESP/XFRM — et non d'un renommage d'une vulnérabilité déjà corrigée. Phoronix note également qu'à l'heure de la publication, une preuve de concept était disponible, et que le correctif consistait en un petit patch à net/core/skbuff.c, qui n'était pas encore intégré dans les branches principales du noyau.
Canonical a attribué CVE-2026-46300 une priorité élevée pour Ubuntu, en indiquant la raison comme « élévation de privilèges locale triviale ». Sur la page de sécurité d'Ubuntu pour les noyaux concernés, l'état au moment de la mise à jour du 13 mai était « Besoin d'évaluation », et il était noté à part que le problème se trouvait également dans le module ESP du noyau et pouvait être atténué temporairement de la même façon que Dirty Frag.
Debian Security Tracker préparait à l'époque des noyaux vulnérables dans les branches bullseye, bookworm, trixie, forky et sid ; pour le paquet linux dans unstable, une version corrigée n'avait pas encore été indiquée.
La mesure de protection temporaire reste la même que pour Dirty Frag : désactiver le chargement des modules esp4, esp6 et rxrpc, s'ils ne sont pas nécessaires au système. Cela peut perturber le fonctionnement des tunnels IPsec sur les nœuds où les configurations kernel ESP, strongSwan, Libreswan ou similaires sont utilisées, donc cette mesure doit être appliquée sur les passerelles VPN seulement après évaluation des conséquences.
Exemple d'atténuation temporaire pour les administrateurs :
sudo sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/dirtyfrag.conf" sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
Si l'on soupçonne que le système a déjà pu être attaqué, la simple désactivation des modules n'est pas suffisante : puisque la démonstration publique modifie le fichier exécutable dans le cache des pages, les administrateurs recommandent de vider le cache des pages ou de redémarrer le système après avoir appliqué les mesures de protection. CloudLinux indique clairement qu'après exploitation, /usr/bin/su peut rester modifié en mémoire jusqu'à ce que les pages correspondantes soient évincées.
Pour supprimer la règle temporaire après l'installation du noyau corrigé, il suffit de supprimer le fichier créé :
sudo rm /etc/modprobe.d/dirtyfrag.conf
La principale recommandation reste standard : installer le noyau corrigé de sa distribution et redémarrer le système. Avant la mise à jour, le plus grand risque concerne les serveurs multi-utilisateurs, les CI runners, l'hébergement mutualisé, les fermes de build en conteneur et toute machine où des utilisateurs non privilégiés ou partiellement de confiance peuvent exécuter du code local.
Source : linux.org.ru
