Fragnesia (CVE-2026-46300) : la troisième escalade de privilèges du noyau Linux en trois semaines et quoi faire

Le 13 mai 2026, le chercheur en sécurité William Bowling et l'équipe V12 Security ont publiquement divulgué Fragnesia (CVE-2026-46300), une nouvelle vulnérabilité d'escalade locale de privilèges du noyau Linux. Une preuve de concept publique fonctionnelle existe et tout utilisateur local non privilégié peut l'utiliser pour obtenir root en une seule commande. C'est le troisième exploit root du noyau nécessitant un correctif en trois semaines, après Copy Fail (CVE-2026-31431) le 29 avril et Dirty Frag (CVE-2026-43284 et CVE-2026-43500) le 7 mai.

Si vous êtes client d'un serveur géré chez Gotekky, votre serveur est déjà protégé. L'atténuation que nous avons déployée pour Dirty Frag la semaine dernière bloque aussi Fragnesia. Aucune action supplémentaire n'est requise sur les serveurs gérés. Le reste de ce guide explique ce qu'est Fragnesia, pourquoi l'atténuation Dirty Frag la couvre, ce qui diffère des deux vulnérabilités précédentes et ce que les opérateurs CloudLinux et AlmaLinux auto-gérés devraient faire aujourd'hui.

Ce qu'est Fragnesia et en quoi elle diffère de Dirty Frag

Fragnesia se situe dans la même zone large du noyau que Dirty Frag (les sous-systèmes XFRM et ESP de la pile réseau Linux) mais c'est un bogue séparé et distinct. Les correctifs Dirty Frag ne l'adressent pas. Le nom vient de la faille logique sous-jacente : pendant le coalescing de réception TCP, le tampon socket oublie qu'un fragment est partagé, ce qui permet à un attaquant d'abuser du chemin ESP-in-TCP pour effectuer des écritures d'octets arbitraires dans le cache de pages du noyau de tout fichier lisible.

Techniquement, quand un socket TCP passe en mode espintcp ULP après que des données ont été splicées d'un fichier dans la file de réception (via splice ou sendfile), le noyau traite ces pages de fichier en file comme du chiffré ESP et les déchiffre en place. Le keystream AES-GCM est XORé dans les pages de fichier en cache et, en contrôlant le nonce IV, un processus non privilégié transforme cela en écriture arbitraire d'un octet dans le cache de pages par invocation déclencheur. La preuve de concept publique écrit un stub ELF indépendant de position de 192 octets dans la copie du cache de pages de /usr/bin/su. La prochaine invocation de su exécute le code modifié et accorde root à l'attaquant.

Le schéma est le même que Copy Fail et Dirty Frag : écrire dans le cache de pages, pas sur disque. La surveillance d'intégrité de fichiers ne voit rien. Les redémarrages effacent la modification car la mémoire est réinitialisée, mais à ce moment l'attaquant a déjà établi la persistance par d'autres moyens. Aucune condition de course n'est requise. L'exploit est déterministe en une seule commande.

Pourquoi l'atténuation Dirty Frag vous protège

Le chemin d'attaque Fragnesia nécessite que les modules noyau esp4 ou esp6 soient chargés. L'atténuation Dirty Frag que nous avons recommandée la semaine dernière met précisément ces modules sur liste noire avec rxrpc, ipcomp4 et ipcomp6. Un serveur qui a appliqué cette atténuation ne peut pas charger les modules dont Fragnesia a besoin pour s'exécuter. La protection est incidente mais complète.

Cela signifie que les serveurs Gotekky gérés et tout serveur auto-géré où l'atténuation Dirty Frag a été appliquée la semaine dernière sont déjà protégés contre Fragnesia. Vérifiez avec :

cat > /root/check-fragnesia-protection.sh <<'EOF'
#!/usr/bin/env bash

RED="\033[31m"
GREEN="\033[32m"
BLUE="\033[34m"
BOLD="\033[1m"
RESET="\033[0m"

PASS_COUNT=0
WARN_COUNT=0

pass() {
  echo -e "${GREEN}OK${RESET} : $1"
  PASS_COUNT=$((PASS_COUNT + 1))
}

warn() {
  echo -e "${RED}ATTENTION${RESET} : $1"
  WARN_COUNT=$((WARN_COUNT + 1))
}

info() {
  echo -e "${BLUE}$1${RESET}"
}

check_module() {
  local mod="$1"

  echo
  info "Vérification du module noyau : $mod"

  if modprobe -n -v "$mod" 2>/dev/null | grep -qE 'install /bin/false|install /bin/true'; then
    pass "$mod est bloqué par une règle modprobe."
  elif modprobe "$mod" >/dev/null 2>&1; then
    warn "$mod semble pouvoir être chargé. La mitigation doit être vérifiée."
  else
    pass "$mod ne peut pas être chargé."
  fi
}

clear
echo -e "${BOLD}Vérification de la protection Fragnesia${RESET}"
echo "========================================"

check_module esp4
check_module esp6
check_module ipcomp4
check_module ipcomp6
check_module rxrpc

echo
info "Vérification des namespaces utilisateur non privilégiés"

NS_VALUE="$(sysctl -n user.max_user_namespaces 2>/dev/null || echo inconnu)"

if [ "$NS_VALUE" = "0" ]; then
  pass "user.max_user_namespaces est défini à 0."
else
  warn "user.max_user_namespaces est défini à $NS_VALUE, pas à 0."
fi

echo
echo -e "${BOLD}Résumé${RESET}"
echo "------"

if [ "$WARN_COUNT" -eq 0 ]; then
  echo -e "${GREEN}Protégé : toutes les vérifications sont réussies.${RESET}"
else
  echo -e "${RED}Vérification requise : $WARN_COUNT avertissement(s) trouvé(s).${RESET}"
fi

echo
echo "Vérifications réussies : $PASS_COUNT"
echo "Avertissements : $WARN_COUNT"

echo
echo -e "${BOLD}Détails techniques pour administrateurs${RESET}"
modprobe -c | egrep '^(install|blacklist) (esp4|esp6|ipcomp4|ipcomp6|rxrpc)' || echo "Aucune règle modprobe liée à Fragnesia trouvée."
EOF

chmod +x /root/check-fragnesia-protection.sh
/root/check-fragnesia-protection.sh

Si toutes les vérifications réussissent sans avertissement, aucune action supplémentaire n'est nécessaire pour Fragnesia jusqu'à ce que des noyaux corrigés soient publiés. Si un module semble pouvoir être chargé, l'atténuation Dirty Frag n'a jamais été appliquée ou a été retirée, et le serveur est vulnérable à la fois à Dirty Frag et Fragnesia simultanément.

Ce que cela signifie pour les versions CloudLinux affectées spécifiquement

CloudLinux a confirmé que Fragnesia affecte CloudLinux 7h, 8, 9 et 10. CloudLinux 7 (l'originale, pas 7h) n'est pas affectée car elle livre un noyau plus ancien antérieur au chemin de code vulnérable. CloudLinux prépare des noyaux corrigés et des livepatches KernelCare pour toutes les versions affectées. Le livepatch KernelCare sera le chemin le plus propre pour les serveurs de production : il applique le correctif au noyau en cours d'exécution sans redémarrage requis.

AlmaLinux 8, 9 et 10 sont aussi affectées car elles partagent le même code noyau amont. Les noyaux corrigés AlmaLinux pour Fragnesia sont en test au moment d'écrire ces lignes et passeront en dépôts de production une fois vérifiés. Le chemin de mise à jour sur AlmaLinux est le dnf upgrade kernel standard suivi d'un redémarrage, identique au flux de correctif Dirty Frag.

Ce que Gotekky a fait sur les serveurs gérés

L'atténuation Dirty Frag que nous avons déployée la semaine dernière (mise sur liste noire de esp4, esp6, rxrpc, ipcomp4 et ipcomp6 sur tous les serveurs gérés et application du sysctl espaces de noms utilisateur non privilégiés sur les nœuds AlmaLinux 7) bloque déjà le chemin d'exploitation Fragnesia. Nous avons vérifié l'état des modules sur chaque serveur géré dans les heures suivant la divulgation Fragnesia et confirmé que tous sont protégés.

Pour les serveurs gérés CloudLinux avec abonnements KernelCare, nous appliquerons le livepatch Fragnesia dès qu'il sera publié, éliminant le besoin de redémarrage. Pour les nœuds AlmaLinux, nous appliquerons le noyau corrigé pendant la prochaine fenêtre de maintenance planifiée, identique au déploiement Dirty Frag. La liste noire intermédiaire des modules reste en place pendant tout le processus. Les clients n'ont pas besoin d'agir.

Si vous exploitez des serveurs auto-gérés, faites ceci aujourd'hui

L'arbre de décision est le même que Dirty Frag avec un ajout : vérifiez que l'atténuation est en place, puis videz le cache de pages pour annuler toute altération en mémoire antérieure qui aurait pu se produire avant l'application de l'atténuation.

Si vous avez déjà appliqué la liste noire de modules Dirty Frag

Vous êtes protégé contre Fragnesia. Vérifiez avec les commandes modprobe ci-dessus. Après avoir confirmé que les modules sont bloqués, videz le cache de pages pour vous assurer qu'aucune altération en mémoire d'une tentative d'exploitation antérieure ne reste. En tant que root :

sync
echo 3 > /proc/sys/vm/drop_caches

Cela force le noyau à libérer les pages de fichiers mises en cache et à les recharger depuis le disque au prochain accès. Toute modification qu'un attaquant aurait pu écrire dans les copies en mémoire des binaires est effacée. C'est une opération à faible impact mais elle causera un bref pic d'E/S à mesure que les fichiers fréquemment accédés se rechargent.

Si vous n'avez pas appliqué la liste noire de modules Dirty Frag

Appliquez-la maintenant. L'atténuation est le même fichier de configuration unique :

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install ipcomp4 /bin/false
install ipcomp6 /bin/false
install rxrpc /bin/false
EOF

# Décharger les modules actuellement chargés
rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

# Vider le cache de pages
sync
echo 3 > /proc/sys/vm/drop_caches

Cela bloque à la fois Dirty Frag et Fragnesia simultanément. Comme noté dans le guide Dirty Frag, la liste noire casse les connexions VPN IPsec (esp4, esp6) et les montages Andrew File System (rxrpc). Vérifiez qu'aucun client ou service ne dépend de ceux-ci sur vos serveurs avant d'appliquer.

CloudLinux avec KernelCare

Si vous exécutez CloudLinux 7h, 8, 9 ou 10 avec KernelCare, le livepatch pour Fragnesia sera livré automatiquement une fois que CloudLinux le publie. Vérifiez le statut avec :

kcarectl --update
kcarectl --patch-info | grep CVE-2026-46300

Si le CVE apparaît comme corrigé, vous avez terminé. Aucun redémarrage, aucune liste noire de modules nécessaire. Si vos serveurs CloudLinux n'ont pas KernelCare et qu'un redémarrage n'est pas réalisable immédiatement, appliquez la liste noire des modules comme mesure intermédiaire et planifiez la mise à niveau du noyau pour la prochaine fenêtre de maintenance.

AlmaLinux 8, 9, 10

Une fois qu'AlmaLinux déplace le noyau corrigé Fragnesia du test à la production (probablement dans les 24 à 48 heures suivant la divulgation), mettez à jour et redémarrez :

sudo dnf clean metadata
sudo dnf upgrade kernel
sudo reboot

Jusque-là, la liste noire des modules est votre protection.

Les clients Imunify360 ont une couverture supplémentaire

Si vous exécutez Imunify360 sur vos serveurs, il bloque déjà l'exploit Fragnesia via sa détection d'exploitation en temps réel. CloudLinux confirme qu'Imunify360 utilise des heuristiques étendues pour identifier et atténuer les nouveaux indicateurs liés à cette classe de vulnérabilité. C'est une couche de défense supplémentaire plutôt qu'un remplacement de la mise à jour du noyau ou de la liste noire des modules, mais elle fournit une couverture pendant la fenêtre avant l'application d'un noyau corrigé. Les clients exécutant Imunify360 sont protégés contre les tentatives d'exploitation actuellement observées en attendant.

Le schéma que cela représente et ce que cela signifie pour l'infrastructure d'hébergement

Trois vulnérabilités d'escalade de privilèges du noyau Linux en trois semaines n'est pas une coïncidence. Copy Fail, Dirty Frag et Fragnesia sont des bogues différents, trouvés par des chercheurs différents, dans des sous-systèmes différents du noyau, mais ils partagent le même schéma d'exploitation : écrire dans le cache de pages pour modifier des binaires privilégiés en mémoire, puis déclencher ces binaires pour un root instantané. La cadence de découverte reflète deux tendances. Premièrement, l'outillage de revue de code assisté par IA est maintenant véritablement efficace pour trouver des primitives déterministes comme celle-ci. Deuxièmement, le schéma cache-de-pages-vers-root est une classe de vulnérabilités plutôt qu'un seul bogue, et une fois qu'un chercheur a démontré que cela fonctionne, d'autres ont commencé à chercher des primitives similaires.

Pour l'infrastructure d'hébergement, la réalité opérationnelle est que cette cadence est peu susceptible de ralentir bientôt. La défense en profondeur à travers le durcissement du noyau, l'application rapide des correctifs, la surveillance, l'isolation entre comptes clients et idéalement des noyaux par locataire via des technologies comme les microVMs est maintenant la base. L'atténuation Dirty Frag a maintenant bloqué deux vulnérabilités (Dirty Frag et Fragnesia) avec le même fichier de configuration, ce qui est le bon type de défense : assez large pour attraper les bogues futurs liés sans nécessiter d'atténuation personnalisée pour chaque nouvelle divulgation. Si une quatrième vulnérabilité du noyau XFRM/ESP est divulguée la semaine prochaine, la même atténuation la couvrira probablement aussi. Ce n'est pas une garantie, mais c'est le schéma qui s'est maintenu sur trois divulgations jusqu'à présent.

Gotekky maintient des guides séparés pour Copy Fail et Dirty Frag avec tout le détail technique et opérationnel de chacun. Lisez-les en parallèle avec ce guide si vous ne l'avez pas déjà fait, particulièrement si vous exploitez des serveurs auto-gérés qui auraient pu manquer l'atténuation précédente.