Copy Fail / Dirty Frag Mitigation for Yandex Managed Kubernetes

Automatic application of mitigation for vulnerabilities CVE-2026-31431, CVE-2026-43284 and CVE-2026-43500 in the Linux kernel on all worker nodes of a Yandex Managed Kubernetes cluster.

Vulnerability Description

CVE ID: CVE-2026-43284, CVE-2026-43500

CVE link: https://nvd.nist.gov/vuln/detail/CVE-2026-43284

Original reports:

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

Brief description:

Dirty Frag is a class of logic vulnerabilities in the Linux kernel that allows an unprivileged local user to gain superuser (root) privileges. Exploitation combines two independent page-cache write primitives in the xfrm-ESP and RxRPC subsystems, each of which is self-sufficient for privilege escalation.

Copy Fail 2: Electric Boogaloo is an independent PoC exploiting the xfrm-ESP primitive (CVE-2026-43284). By vulnerability class it is similar to the original Copy Fail (CVE-2026-31431), so this DaemonSet retains mitigation for both the original AF_ALG scenario and the new Dirty Frag variants.

Attack:

does not require remote access - only an unprivileged local account
is a deterministic logic bug without race condition - succeeds on the first attempt
does not cause a kernel panic on failed exploitation
can be used as a container-to-host escape primitive, since the page cache is shared across the entire node

The root cause of both variants is the same: when using splice() / MSG_SPLICE_PAGES, the kernel places page cache pages directly into socket buffer fragments (skb). The xfrm-ESP and RxRPC subsystems perform in-place decryption over such fragments without checking whether they are private. As a result, the attacker gains controlled write access to the page cache of any readable file.

Affected technologies:

Linux kernel, net/ipv4/esp4.c / net/ipv6/esp6.c subsystem (xfrm-ESP)
Linux kernel, net/rxrpc/rxkad.c subsystem (RxRPC / RxKAD)
splice() / vmsplice() system calls combined with UDP sockets (ESP-in-UDP) and AF_RXRPC
Mitigation for the original Copy Fail (CVE-2026-31431) is separately retained via blocking AF_ALG (algif_aead)

The vulnerability does not directly affect AF_ALG (algif_aead) as part of Dirty Frag - that is a separate Copy Fail vulnerability (CVE-2026-31431). Also not directly affected are dm-crypt / LUKS, kTLS, in-kernel TLS, and IPsec in tunnel mode without UDP encapsulation.

Attack vector and severity level according to CVSS v.3.1:

Base score: not assigned at the time of publication.

By nature, the vulnerability is similar to 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) - it is a local privilege escalation without race condition.

What this fix does

The DaemonSet automatically performs the following on each worker node of the cluster:

Checks AF_ALG availability - runs a quick test for the original Copy Fail scenario
Blocks vulnerable modules - creates /etc/modprobe.d/blacklist-lpe.conf with rules for algif_aead, esp4, esp6 and rxrpc
Unloads modules - runs rmmod for algif_aead, esp4, esp6 and rxrpc if they are loaded
Drops page cache and verifies configuration - clears caches and checks for the presence of the configuration file
Monitors state - checks for the configuration every hour and reloads modules if necessary

Quick Start

1. Download the DaemonSet

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

Or clone the repository:

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

2. Apply the fix

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

3. Check the application status

# Check the DaemonSet status
kubectl get daemonset -n kube-system cve-2026-31431-fix

# See on how many nodes the fix has been applied
kubectl get pods -n kube-system -l app=cve-2026-31431-fix -o wide

4. View the fix application logs

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

# Main container logs (monitoring)
kubectl logs -n kube-system -l app=cve-2026-31431-fix -c monitor

Example of successful application

=========================================
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
=========================================

Manual vulnerability check

You can manually check for the vulnerability on a node. Connect to the node via SSH and run:

# Check availability of the original Copy Fail scenario 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")'

# If it outputs "AF_ALG AEAD available - VULNERABLE" - the system is vulnerable
# If it outputs an error - the system is protected

Check the configuration:

# Check for the blocking configuration
cat /etc/modprobe.d/blacklist-lpe.conf

# Expected output:
# install algif_aead /bin/false
# install esp4 /bin/false
# install esp6 /bin/false
# install rxrpc /bin/false

Check that the vulnerable modules are not loaded:

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

Removing the fix

If you need to delete the DaemonSet:

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

Important: Deleting the DaemonSet will not remove the configuration files from the nodes. The /etc/modprobe.d/blacklist-lpe.conf file will remain in place and will continue to protect the system.

To completely remove the fix from the nodes, you need to connect to each node via SSH and manually delete the file:

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

Technical details

Permissions used:

hostPID: true - for access to host processes via nsenter
privileged: true - for writing to /etc and unloading kernel modules
Volume mount / - for access to the host filesystem

Image: ubuntu:22.04

Resources:

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

Compatibility

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

License

Apache License 2.0

See LICENSE for details.

Support

If you encounter any issues, create an issue in the repository.

yc-mk8s-copy-fail-mitigation

Most Popular