Copy Fail (CVE-2026-31431): 732 Bytes to Root on Every Linux Distribution

A new Linux kernel vulnerability, CVE-2026-31431, lets any unprivileged local user become root on essentially every Linux distribution shipped since 2017. The exploit is a 732-byte Python script using only standard library modules. It requires no race conditions, no timing windows, no version-specific payloads. The researchers at Xint (Theori) who discovered and disclosed it call it Copy Fail.

What is Copy Fail?

Copy Fail is a logic flaw in the Linux kernel's authencesn cryptographic template. It chains three kernel components into a deterministic, controlled 4-byte write into the page cache of any readable file on the system:

1. authencesn scratch write uses destination memory as temporary scratch space, writing 4 bytes of attacker-controlled data beyond its intended boundary — a bug introduced by 2017's in-place optimization.
2. AF_ALG socket interface exposes this cryptographic operation to unprivileged userspace through standard sockets.
3. splice() system call delivers page cache pages into the writable destination scatterlist, making files like /etc/passwd reachable by the scratch write.

When these elements intersect, an attacker can corrupt the cached copy of any readable file with exactly 4 bytes of controlled data. The disclosed proof-of-concept overwrites the UID field in /etc/passwd's page cache — changing the attacker's user ID from 1000 to 0000 (root). Since the corruption lives in memory and not on disk, file integrity tools like AIDE and Tripwire report the system as clean. When the attacker runs su with their own password, the system grants root privileges based on the corrupted cached identity.

The root cause is a 2017 in-place optimization in algif_aead (commit 72548b0) that allowed source and destination scatterlists to share memory. The fix (commit a664bf3d603d) reverts to out-of-place processing, separating them so page cache pages can no longer end up in writable memory regions. As the commit message explains:

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.

The patch is a net removal of over 90 lines of branching logic, offset calculations, and conditional memory management across crypto/af_alg.c, crypto/algif_aead.c, crypto/algif_skcipher.c, and include/crypto/if_alg.h. The key changes:

• af_alg_count_tsgl() and af_alg_pull_tsgl() are simplified by removing offset parameters that enabled the in-place path
• The _aead_recvmsg() function drops the conditional encryption/decryption paths that chained page cache pages into the writable destination scatterlist
• Associated data is now copied directly via memcpy_sglist() instead of being shared between source and destination

Why this one matters

Unlike prior privilege escalation vulnerabilities like Dirty Cow or Dirty Pipe, Copy Fail:

• Requires no race conditions or timing windows. The exploit is deterministic.
• Works identically across distributions without version-specific modifications.
• Bypasses file integrity verification because the corruption is in the page cache, not on disk.
• Crosses container boundaries via the shared page cache, making it a threat to multi-tenant environments.

The CVSS v3.1 score is 7.8 (High) with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, reflecting local access with low complexity, low privileges, and high impact across confidentiality, integrity, and availability.

Affected systems and patch status

The vulnerability affects every mainstream Linux distribution since the 2017 kernel optimization. The mainline kernel patch (commit a664bf3d603d) was merged on April 1, 2026. As of April 30, most distributions have not yet shipped updated kernel packages.

Every major vendor rates this Important or High with a CVSS 7.8 score. Red Hat initially listed this as Moderate severity with fix deferred on their public CVE page, which drew criticism in the r/sysadmin discussion given the trivial exploitability. Red Hat's own security data API and Bugzilla #2460538 rate it Important (CVSS 7.8), and the deferred status has since been removed.

RHEL 9 and its rebuilds: standard mitigation does not work

RHEL 9, AlmaLinux 9, Rocky Linux 9, and Oracle Linux 9 share a specific complication: the cryptographic algorithm APIs are compiled directly into the kernel (CONFIG_CRYPTO_ALGAPI=y) rather than as loadable modules. The standard mitigation of disabling the algif_aead module with modprobe does not work on these systems because the module cannot be unloaded. A workaround using initcall_blacklist=algif_aead_init as a bootloader parameter has been confirmed effective, but a kernel update is the only complete fix.

What to do now

1. Patch the kernel

Update to a kernel version containing mainline commit a664bf3d603d, which reverts the 2017 in-place optimization. This is the definitive fix.

2. If you cannot patch immediately, disable the module

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

This has negligible performance impact. Most systems do not use the AF_ALG userspace crypto interface. Applications explicitly configured for afalg in OpenSSL will fall back to standard userspace crypto libraries.

For RHEL 9, AlmaLinux 9, Rocky Linux 9, Oracle Linux 9, and other distributions that compile algif_aead into the kernel, the module cannot be unloaded. Use the bootloader parameter instead:

BashCopy
grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init

3. Block AF_ALG in untrusted workloads

Regardless of patch status, block AF_ALG socket creation via seccomp for containers, CI runners, and sandboxed environments. This is especially critical for multi-tenant Kubernetes clusters and cloud platforms running user-supplied workloads.

Important: Kubernetes RuntimeDefault seccomp does not block AF_ALG sockets. You need a custom seccomp profile. Create a file that blocks socket() when the first argument is AF_ALG (address family 38):

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

Place this file on each node at /var/lib/kubelet/seccomp/block-af-alg.json (see the Kubernetes seccomp tutorial for details), then reference it in your pod spec:

YAMLCopy
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: block-af-alg.json

For Docker, pass the profile directly with --security-opt seccomp=block-af-alg.json.

Prioritize by environment

Not all systems face the same risk:

• Critical (patch immediately): Multi-tenant hosts, shared development servers, Kubernetes clusters, CI/CD runners executing untrusted code, cloud SaaS platforms with user-supplied containers.
• High: Single-tenant production servers where an attacker with local access could escalate to root.
• Moderate: Single-user workstations where the attacker already has code execution as the user.

Detect with Mondoo

Mondoo customers can identify affected systems through vulnerability intelligence for CVE-2026-31431. Mondoo continuously scans your infrastructure and will flag any system running a vulnerable kernel version, giving you a clear view of your exposure across cloud instances, containers, and on-premises servers.

Disclosure timeline

References

• Copy Fail: 732 Bytes to Root on Every Major Linux Distribution (Xint/Theori, original research)
• Copy Fail official site
• Commit 72548b0 introducing the vulnerability (2017) — the in-place optimization in algif_aead
• Commit a664bf3d603d fixing the vulnerability — reverts to out-of-place processing
• Mondoo Vulnerability Intelligence: CVE-2026-31431
• Red Hat CVE-2026-31431
• Amazon Linux CVE-2026-31431
• SUSE CVE-2026-31431
• AlmaLinux mitigation discussion