Au cœur Linux Une autre vulnérabilité locale d'élévation de privilèges a été divulguée, baptisée Fragnesia et identifiant CVE-2026-46300Ce problème appartient à la même catégorie d'attaques de cache de page que les problèmes récemment évoqués de Copy Fail et Dirty Frag, mais il ne s'agit pas d'une nouvelle publication d'un ancien bug : c'est un défaut distinct dans le code. XFRM ESP-in-TCP.
La vulnérabilité a été découverte par un chercheur. William Bowling de l'équipe Sécurité V12D'après la description publiée, Fragnesia permet à un utilisateur local non privilégié de modifier le contenu de fichiers en lecture seule dans la mémoire cache des pages, exécutant ainsi du code avec les privilèges root. Contrairement à de nombreuses anciennes vulnérabilités d'exécution de code (LPE), cette attaque ne nécessite pas de condition de concurrence et est qualifiée de déterministe par les chercheurs.
Techniquement, le problème provient du fait que le noyau perd la notion qu'un fragment de données est « partagé » et associé à une page mémoire externe, y compris le cache de pages, lors de la fusion de tampons réseau. Le correctif proposé décrit cela comme un bogue dans la fonction `skb_try_coalesce()` : lors du transfert de fragments paginés d'un tampon réseau à un autre, l'indicateur `SKBFL_SHARED_FRAG` n'est pas conservé. Par conséquent, le code ESP ultérieur pourrait considérer, à tort, le tampon comme modifiable.
Concrètement, cela signifie que des données précédemment mises en file d'attente depuis un fichier vers la file d'attente TCP peuvent être traitées par le noyau comme du texte chiffré ESP après le passage du socket en mode espintcp. Lors du déchiffrement AES-GCM, les octets sont modifiés directement dans le cache de pages associé au fichier. Cela ne modifie pas le fichier sur le disque, mais change sa représentation en mémoire avant que la page ne soit supprimée du cache.
La démonstration d'attaque publiée ciblait /usr/bin/su : l'exploit modifiait les premiers octets d'un fichier binaire dans le cache de pages, puis exécutait la copie modifiée en mémoire, obtenant ainsi un accès shell avec les privilèges root. Le fichier original sur le disque restait inchangé, ce qui rendait le diagnostic particulièrement difficile : les traces d'exploitation pouvaient disparaître après avoir vidé le cache de pages ou redémarré le système.
Fragnesia est apparue moins d'une semaine après Dirty Frag. V12 souligne qu'il s'agit d'un bug distinct au sein de la même surface d'attaque (ESP/XFRM) et non d'un changement de nom d'une vulnérabilité déjà corrigée. Phoronix précise également qu'une preuve de concept était disponible au moment de la publication et que le correctif consistait en un petit patch du fichier net/core/skbuff.c qui n'avait pas encore été immédiatement intégré aux branches principales du noyau.
Approprié canonique CVE-2026-46300 haute priorité pour Ubuntu, en indiquant comme motif une « simple escalade de privilèges locale ». Sur la page Ubuntu Le correctif de sécurité pour les noyaux concernés était indiqué comme « Nécessite une évaluation » au moment de la mise à jour du 13 mai, et la note précisait que le problème se situait également dans le module ESP du noyau et pouvait être temporairement atténué de la même manière que Dirty Frag.
Debian Suivi de sécurité Au moment de l'examen, les noyaux des branches bullseye, bookworm, trixie, forky et sid étaient marqués comme vulnérables ; le paquet linux dans unstable n'avait pas encore reçu de version corrigée.
La protection temporaire reste la même que pour Dirty Frag : désactiver le chargement du module Les modules ESP4, ESP6 et RXRPC peuvent être désactivés s'ils ne sont pas nécessaires au système. Cette désactivation peut perturber les tunnels IPsec sur les nœuds utilisant ESP au niveau du noyau, StrongSwan, Libreswan ou des configurations similaires ; par conséquent, cette mesure ne doit être appliquée aux passerelles VPN qu'après mûre réflexion.
Exemple de clémence 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 || vrai
S’il existe un soupçon que le système a déjà été attaqué, le blocage des modules ne suffit pas : étant donné que la démonstration publique modifie le fichier exécutable dans le cache de pages, les administrateurs recommandent de vider le cache de pages ou de redémarrer le système après avoir appliqué les mesures de sécurité.Linux indique explicitement qu'après exploitation, /usr/bin/su peut rester modifié en mémoire jusqu'à ce que les pages correspondantes soient supprimées.
Pour supprimer une règle temporaire après l'installation du noyau modifié, vous pouvez supprimer le fichier créé :
sudo rm /etc/modprobe.d/dirtyfrag.conf
La principale recommandation reste inchangée : installez le noyau corrigé pour votre distribution et redémarrez le système. Avant la mise à jour, les serveurs multi-utilisateurs, les plateformes d’intégration continue, l’hébergement mutualisé, les fermes de conteneurs et toute machine où des utilisateurs non privilégiés ou partiellement dignes de confiance peuvent exécuter du code local présentent le risque le plus élevé.
Source: linux.org.ru
