Copy Fail / Dirty Frag Mitigation for Yandex Managed Kubernetes

Application automatique de la mitigation pour les vulnérabilités CVE-2026-31431, CVE-2026-43284 et CVE-2026-43500 dans le noyau Linux sur tous les nœuds worker du cluster Yandex Managed Kubernetes.

Description de la vulnérabilité

Identifiant CVE (CVE ID) : CVE-2026-43284, CVE-2026-43500

Lien vers le CVE : https://nvd.nist.gov/vuln/detail/CVE-2026-43284

Rapport d'origine :

Dirty Frag (PoC et write-up) : https://github.com/V4bel/dirtyfrag
Copy Fail 2: Electric Boogaloo (PoC xfrm-ESP) : https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo
Liste de diffusion oss-security : https://www.openwall.com/lists/oss-security/2026/05/07/8

Description succincte :

Dirty Frag est une classe de vulnérabilités logiques dans le noyau Linux permettant à un utilisateur local non privilégié d'obtenir les droits de superutilisateur (root). L'exploitation combine deux primitives d'écriture indépendantes dans le page cache des sous-systèmes xfrm-ESP et RxRPC, chacune étant autonome pour l'élévation de privilèges.

Copy Fail 2: Electric Boogaloo est un PoC indépendant exploitant la primitive xfrm-ESP (CVE-2026-43284). Par classe de vulnérabilité, il est analogue au Copy Fail d'origine (CVE-2026-31431), c'est pourquoi ce DaemonSet conserve la mitigation à la fois pour le scénario AF_ALG d'origine et pour les nouvelles variantes de Dirty Frag.

Attaque :

ne nécessite pas d'accès distant - seulement un compte local non privilégié
est un bug logique déterministe sans condition de course - réussit dès la première tentative
ne provoque pas de kernel panic en cas d'échec de l'exploitation
peut être utilisée comme primitive d'évasion de conteneur vers l'hôte, car le page cache est partagé pour tout le nœud

La cause racine des deux variantes est la même : lors de l'utilisation de splice() / MSG_SPLICE_PAGES, le noyau place les pages du page cache directement dans les fragments des buffers de socket (skb). Les sous-systèmes xfrm-ESP et RxRPC effectuent un déchiffrement in-place sur ces fragments, sans vérifier s'ils sont privés. En conséquence, l'attaquant obtient une écriture contrôlée dans le page cache de tout fichier lisible.

Technologies concernées :

Noyau Linux, sous-système net/ipv4/esp4.c / net/ipv6/esp6.c (xfrm-ESP)
Noyau Linux, sous-système net/rxrpc/rxkad.c (RxRPC / RxKAD)
Appels système splice() / vmsplice() combinés avec les sockets UDP (ESP-in-UDP) et AF_RXRPC
La mitigation du Copy Fail d'origine (CVE-2026-31431) est conservée séparément via le blocage de AF_ALG (algif_aead)

La vulnérabilité n'affecte pas directement AF_ALG (algif_aead) en tant que partie de Dirty Frag - il s'agit d'une vulnérabilité distincte Copy Fail (CVE-2026-31431). De même, dm-crypt / LUKS, kTLS, in-kernel TLS et IPsec en mode tunnel sans encapsulation UDP ne sont pas directement affectés.

Vecteur d'attaque et niveau de dangerosité selon CVSS v.3.1 :

Évaluation de base : non attribuée au moment de la publication.

Par nature, la vulnérabilité est analogue à Copy Fail (CVE-2026-31431, 7.8 HIGH, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) - il s'agit d'une élévation de privilèges locale sans condition de course.

Ce que fait ce correctif

Le DaemonSet applique automatiquement sur chaque nœud worker du cluster :

Vérifie la disponibilité de AF_ALG - exécute un test rapide pour le scénario Copy Fail d'origine
Bloque les modules vulnérables - crée /etc/modprobe.d/blacklist-lpe.conf avec des règles pour algif_aead, esp4, esp6 et rxrpc
Décharge les modules - exécute rmmod pour algif_aead, esp4, esp6 et rxrpc, s'ils sont chargés
Réinitialise le page cache et vérifie la configuration - vide les caches et vérifie la présence du fichier de configuration
- vérifie chaque heure la présence de la configuration et recharge les modules si nécessaire

Démarrage rapide

1. Télécharger le DaemonSet

wget https://raw.githubusercontent.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation/main/copy-fail-mitigation-daemonset.yaml

Ou cloner le dépôt :

git clone https://github.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation.git
cd yc-mk8s-copy-fail-mitigation

2. Appliquer le correctif

kubectl apply -f copy-fail-mitigation-daemonset.yaml

3. Vérifier le statut de l'application

# Vérifier le statut du DaemonSet
kubectl get daemonset -n kube-system cve-2026-31431-fix

# Voir sur combien de nœuds le correctif est appliqué
kubectl get pods -n kube-system -l app=cve-2026-31431-fix -o wide

4. Consulter les journaux d'application du correctif

# Journaux de l'initContainer (application du correctif)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c apply-fix

# Journaux du conteneur principal (surveillance)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c monitor

Exemple d'application réussie

=========================================
Copy Fail / Dirty Frag mitigation for Yandex Managed K8s
Node: demo-ru-central1-a-1
Date: Thu May 08 14:00:00 UTC 2026
=========================================

Step 1: Checking vulnerability before fix...
❌ System is VULNERABLE - AF_ALG AEAD interface is accessible

Step 2: Creating modprobe configuration...
✓ Created /etc/modprobe.d/blacklist-lpe.conf

Step 3: Unloading vulnerable modules...
  ✓ algif_aead unloaded
  ✓ esp4 not loaded
  ✓ esp6 not loaded
  ✓ rxrpc not loaded

Step 3.5: Dropping system caches...
✓ System caches cleared

Step 4: Verifying the fix...
✓ Configuration file exists:
install algif_aead /bin/false
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Step 5: Testing if vulnerability is fixed...
✓ AF_ALG AEAD interface is properly blocked

=========================================
✓ Mitigation applied successfully
=========================================

Vérification manuelle de la vulnérabilité

Vous pouvez vérifier manuellement la présence de la vulnérabilité sur un nœud. Connectez-vous au nœud via SSH et exécutez :

# Vérifier la disponibilité du scénario Copy Fail d'origine via AF_ALG
python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("AF_ALG AEAD available - VULNERABLE")'

# Si la sortie affiche "AF_ALG AEAD available - VULNERABLE" - le système est vulnérable
# Si une erreur est renvoyée - le système est protégé

Vérifier la configuration :

# Vérifier la présence de la configuration de blocage
cat /etc/modprobe.d/blacklist-lpe.conf

# Sortie attendue :
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false

Vérifier que les modules vulnérables ne sont pas chargés :

lsmod | egrep 'algif_aead|esp4|esp6|rxrpc'

Suppression du correctif

Si vous devez supprimer le DaemonSet :

kubectl delete -f copy-fail-mitigation-daemonset.yaml

Important : La suppression du DaemonSet ne supprimera pas les fichiers de configuration des nœuds. Le fichier /etc/modprobe.d/blacklist-lpe.conf restera en place et continuera de protéger le système.

Pour supprimer complètement le correctif des nœuds, vous devez vous connecter à chaque nœud via SSH et supprimer manuellement le fichier :

rm /etc/modprobe.d/blacklist-lpe.conf

Détails techniques

Autorisations utilisées :

hostPID: true - pour accéder aux processus de l'hôte via nsenter
privileged: true - pour écrire dans /etc et décharger les modules du noyau
Volume mount / - pour accéder au système de fichiers de l'hôte

Image : ubuntu:22.04

Ressources :

Init container : 10m CPU / 64Mi RAM (requests), 200m CPU / 128Mi RAM (limits)
Monitor container : 5m CPU / 32Mi RAM (requests), 50m CPU / 64Mi RAM (limits)

Namespace : kube-system

Compatibilité

✓ Yandex Managed Kubernetes
✓ Ubuntu 20.04
✓ Ubuntu 22.04
✓ Kubernetes 1.20+

Licence

Apache License 2.0

Voir LICENSE pour plus de détails.

Support

En cas de problème, créez une issue dans le dépôt.

yc-mk8s-copy-fail-mitigation

Populaires