Copy Fail CVE-2026-31431: Linux Kernel Local Privilege Escalation

CVE-2026-31431, named Copy Fail, is a local privilege escalation vulnerability in the Linux kernel discovered and publicly disclosed by Xint Code — a security research team at Theori. The official disclosure site is copy.fail (April 29, 2026).

Most Linux LPEs require a race window or kernel-specific offset. Copy Fail is different: a straight-line logic flaw, no race, no per-distro offsets. The same 732-byte Python script produces a root shell on every Linux distribution shipped since 2017 — Ubuntu, Amazon Linux, RHEL, SUSE, Debian, Arch, Fedora, Rocky, and more — without modification.

The bug chain: one logic error in authencesn, chained through AF_ALG and splice() into a 4-byte page-cache write — silently exploitable for nearly a decade. An unprivileged local user can achieve a controlled write to a page-cache-backed page, then target a setuid binary to escalate to root.

This is not "anyone on the internet becomes root" — but in Kubernetes nodes, shared CI runners, build farms, notebook platforms, and any SaaS infrastructure running user-supplied code, the risk escalates rapidly. The attack works deterministically on the first run.

CISA added CVE-2026-31431 to its Known Exploited Vulnerabilities (KEV) catalog with a remediation deadline of May 15, 2026.

Affected Systems

The vulnerability is tied to the algif_aead module and the kernel userspace crypto API (AF_ALG) surface, affecting kernels built since 2017 (when commit 72548b093ee3 introduced the in-place optimization). Xint Code (Theori) directly verified exploitation on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 15.6. Debian, Arch, Fedora, Rocky Linux, AlmaLinux, Oracle Linux, and embedded Linux distributions running in the same kernel range are equally affected out of the box — the exploit uses no distro-specific offsets.

Vulnerable kernel versions (NVD):

| Kernel Branch | Vulnerable Range | Fixed Version | |---------------|-----------------|---------------| | 4.14.x | ≥ 4.14 | 5.10.254 | | 5.11.x | ≥ 5.11 | 5.15.204 | | 5.16.x | ≥ 5.16 | 6.1.170 | | 6.2.x | ≥ 6.2 | 6.6.137 | | 6.7.x | ≥ 6.7 | 6.12.85 | | 6.13.x | ≥ 6.13 | 6.18.22 | | 6.19.x | ≥ 6.19 | 6.19.12 |

Debian fixed versions:

| Release | Fixed Package | |---------|--------------| | bullseye | 5.10.251-3 (DLA-4560-1) | | bookworm | 6.1.170-1 (DSA-6243-1) | | trixie | 6.12.85-1 (DSA-6238-1) | | forky / sid | Fixed |

Priority systems for remediation:

• Kubernetes nodes and container hosts
• Self-hosted GitHub Actions, GitLab Runner, Jenkins agents, and other CI/CD runners
• Multi-user Linux servers
• Notebook, sandbox, and SaaS infrastructure running customer or tenant code
• Build farms and packaging systems

Single-tenant servers where only a trusted team has shell access present a lower risk profile, but remain in scope — a chained web RCE, stolen SSH key, or compromised deploy key can still reach this vulnerability.

Technical Root Cause: authencesn, AF_ALG, and splice()

CVSS v3.1: 7.8 HIGH — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

The root bug lives in authencesn — the kernel's authenticated encryption with associated data (AEAD) implementation. An in-place optimization introduced in 2017 (commit 72548b093ee3) causes page-cache-backed pages to end up in the writable destination scatterlist. An attacker opens an AF_ALG (kernel crypto API userspace interface) socket and uses splice() to chain into a 4-byte controlled write into a page-cache-backed page.

Because page-cache pages back on-disk files, this write affects what the kernel serves the next time any process reads the same file. The exploit targets /usr/bin/su (or any other setuid binary) — writing a short payload that redirects execution to a root shell. The entire exploit is 732 bytes of Python 3 stdlib code, no dependencies, no offsets, no timing.

The upstream fix (mainline commit a664bf3d603d) reverts the in-place optimization:

"There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly." — Linux kernel commit a664bf3d603d

The NVD description reads: "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place."

The exploit chain does not depend on a race condition or kernel-specific offset. It is deterministic and portable across every distribution shipping the affected kernel range. With the PoC published and multiple working root shells demonstrated on different distributions in a single uncut video, waiting without applying the workaround is not risk management.

Why Kubernetes and CI/CD Runners Are the Priority

Container security is often summarized as "container root is not host root." The caveat is that all containers on a node share the same kernel. A kernel local privilege escalation vulnerability collapses tenant isolation, container boundaries, and runner isolation faster than expected.

Particularly risky scenarios:

• Untrusted pull request code running on self-hosted runners
• User notebook or job scripts sharing a host kernel with other tenants
• Build containers running in privileged mode or with a permissive seccomp profile
• Multi-tenant Kubernetes workloads concentrated on the same node

On these systems, blocking AF_ALG socket creation via seccomp while awaiting the kernel patch significantly reduces exploitability. This control is recommended by Xint Code regardless of patch state for all untrusted workload classes.

Disclosure Timeline

| Date | Event | |------|-------| | 2026-03-23 | Reported to Linux kernel security team by Xint Code (Theori) | | 2026-03-24 | Initial acknowledgment from kernel security team | | 2026-03-25 | Patches proposed and reviewed | | 2026-04-01 | Fix committed to mainline (a664bf3d603d) | | 2026-04-22 | CVE-2026-31431 assigned | | 2026-04-29 | Public disclosure at copy.fail |

The exploit was surfaced by Xint Code's automated security analysis scanning the Linux crypto/ subsystem — approximately one hour of scan time. The PoC is published for defenders to verify their own systems.

Quick Inventory Commands

The following commands provide a starting point for impact analysis. They are not sufficient as standalone security decisions — use them alongside distribution vendor advisories and kernel build information.

# Check current kernel version
uname -a
uname -r

# Check if algif_aead is loaded
lsmod | grep algif_aead || true

# Check for active AF_ALG connections
lsof | grep AF_ALG || true
ss -xa | grep -i alg || true

For container hosts, also review seccomp profiles and workload security contexts:

kubectl get pods -A -o wide
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.securityContext.seccompProfile.type}{"\n"}{end}'

Temporary Mitigation (Workaround)

Until the vendor kernel patch is available, the recommended interim step from copy.fail and the Theori team is to disable the algif_aead module:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

After applying this change, verify that no applications on the affected host use AF_ALG directly:

lsof | grep AF_ALG || true
ss -xa | grep -i alg || true

Alternatively, Red Hat's guidance offers boot argument mitigations:

# Block the specific affected module init
initcall_blacklist=algif_aead_init

# Or block the entire af_alg interface
initcall_blacklist=af_alg_init

# Or block the affected algorithm
initcall_blacklist=crypto_authenc_esn_module_init

This workaround generally does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS default builds, SSH, or the kernel keyring crypto — those use the in-kernel crypto API directly without going through AF_ALG. Applications specifically using the afalg engine or direct aead/skcipher/hash sockets should be reviewed with lsof | grep AF_ALG.

Container and Pipeline Hardening

On systems running untrusted workloads, disabling the kernel module alone is not enough. Block AF_ALG socket creation via seccomp — this control can remain as a defense layer even after patching.

Goals for Docker/Podman and Kubernetes:

• Block AF_ALG socket creation from within containers.
• Reduce the number of privileged containers.
• Review HostPath mounts and broad Linux capability grants.
• Run build runners on ephemeral, isolated node pools.
• Separate untrusted PR jobs from production credential access.

Example seccomp rule addition to block socket family AF_ALG (family number 38 on Linux):

{
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ALLOW",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ",
          "action": "SCMP_ACT_ERRNO"
        }
      ]
    }
  ]
}

Patch Strategy

The temporary mitigation is not a replacement for the kernel patch. Once your distribution releases the updated kernel package:

1. Confirm the vendor advisory and verify the patch addresses CVE-2026-31431.
2. Install the kernel update in a test environment first.
3. Plan the reboot window — kernel updates require a restart.
4. Roll out CI runners and Kubernetes node pools in waves.
5. After patching, re-evaluate whether the algif_aead disable should remain based on application dependencies.
6. Keep the seccomp restriction permanently for untrusted workload classes.

Eresus Perspective

Copy Fail demonstrates why "local-only" vulnerabilities should not be deprioritized in modern infrastructure. A local privilege escalation may not be directly exploitable from the internet — but in CI/CD, container, and SaaS sandbox architectures, an attacker may already have a controlled code execution opportunity through a job runner, a pull request pipeline, or a container breakout path.

The right questions are not just "is the CVE patched?":

• Which hosts are running untrusted workloads?
• Which runners have access to production secrets?
• Which Kubernetes node pools have mixed-trust workloads?
• On which systems will patching be operationally delayed?
• Which temporary mitigations can be applied in an observable and reversible way?

Without answers to these questions, "waiting for the patch" is not risk management.

FAQ

Is this remotely exploitable?

The disclosed scenario is local privilege escalation. However, chained with a web RCE, compromised SSH access, a CI/CD job, a notebook session, or a tenant-supplied container, the impact can reach root.

Are all Linux systems equally at risk?

No. Multi-tenant hosts, Kubernetes nodes, build runners, and systems executing user-supplied code are the highest priority. Single-tenant servers accessible only to trusted users still need patching but can be scheduled differently.

Does seccomp replace the kernel patch?

No. Seccomp is a strong temporary and permanent defense layer, particularly in container and pipeline environments. The permanent fix is the vendor kernel patch.

What should we do right now?

Inventory your hosts, check for algif_aead module load status, apply the temporary mitigation on hosts running untrusted workloads, open patch tracking, and plan the reboot window.

Checklist

• [ ] Kernel version and distribution advisory checked
• [ ] algif_aead module load status verified per host
• [ ] Applications using AF_ALG identified
• [ ] Kubernetes node and CI runner inventory completed
• [ ] Untrusted workload classes isolated
• [ ] AF_ALG socket creation blocked via seccomp on container hosts
• [ ] Vendor kernel patch tracking opened with reboot planning
• [ ] Post-patch verification commands added to runbook