---
title: "‘Copy Fail’ (CVE-2026-31431): A New Linux Kernel Flaw Hands Root to Any Local User"
slug: linux-copy-fail-cve-2026-31431-root-vulnerability
category: tech
category_label: "Tech"
author: "BrainWavePost Staff"
date: 2026-04-30
tags: ["linux", "security", "vulnerability", "cve", "kernel", "open source"]
read_time_minutes: 11
canonical_url: https://brainwavepost.com/article/linux-copy-fail-cve-2026-31431-root-vulnerability
source: BrainWavePost
---

# ‘Copy Fail’ (CVE-2026-31431): A New Linux Kernel Flaw Hands Root to Any Local User

*Tech · 2026-04-30 · BrainWavePost Staff · 11 min read*

> A nine-year-old logic bug in the Linux kernel's crypto subsystem lets any unprivileged local user gain root on virtually every major distribution shipped since 2017. Here is a sourced, comprehensive breakdown of CVE-2026-31431 — what it is, who is affected, and how to mitigate it now.

On 29 April 2026, security researchers at Theori publicly disclosed CVE-2026-31431, a high-severity local privilege escalation (LPE) vulnerability in the Linux kernel that they have nicknamed 'Copy Fail'. According to advisories from Theori, Help Net Security, The Register, CERT-EU, Sysdig and Orca Security, the flaw affects virtually every mainstream Linux distribution shipping a kernel released between 2017 and the patch date — including Ubuntu, Debian, Red Hat Enterprise Linux, SUSE, Amazon Linux, Rocky Linux, AlmaLinux, Fedora, Arch and Oracle Linux.

> **Source transparency** _(info)_
>
> All facts in this article are drawn from the researchers' technical write-up at copy.fail and xint.io, the upstream Linux kernel commit, the CERT-EU Security Advisory 2026-005, Help Net Security, The Register, Sysdig, Orca Security and the official security trackers from Ubuntu, SUSE and Red Hat. Links are listed at the end.

## At a glance

- **CVE-2026-31431** — Tracking ID
- **7.8 / 10** — CVSS v3 base score (High) — CERT-EU
- **Since 2017** — Affected kernels (4.13 and later)

## What is ‘Copy Fail’?

Copy Fail is a logic bug in the Linux kernel's userspace crypto API. Specifically, it lives in algif_aead.c — the AEAD socket interface exposed via AF_ALG — and in the authencesn cryptographic template, an AEAD wrapper used by IPsec.

According to Theori, the vulnerability emerged from the interaction of three reasonable kernel changes made over several years: the addition of authencesn in 2011, the introduction of AF_ALG AEAD socket support in 2015, and an in-place optimisation added to algif_aead.c in 2017 (commit 72548b093ee3). Individually each change was sound; combined, they let an unprivileged local user place a page-cache page into a writable destination scatterlist and trigger a controlled four-byte write into that page.

By chaining an AF_ALG socket operation with the splice() system call, an attacker can target the page cache backing any readable file — for example a setuid binary like /usr/bin/su — and corrupt it in memory just enough to obtain a root shell.

> **Why this matters** _(tip)_
>
> Local privilege escalation flaws don't grant remote access on their own, but they are the second half of nearly every modern intrusion: a web RCE landing as an unprivileged service account, an SSH foothold, or a malicious pull request on a CI runner can be combined with Copy Fail to reach root almost instantly (Theori; Help Net Security).

## Why this one is unusually dangerous

Help Net Security and Sysdig both highlight several properties that make Copy Fail more practical to exploit than past Linux kernel LPEs such as Dirty COW (CVE-2016-5195) or Dirty Pipe (CVE-2022-0847):

- The published proof-of-concept is a 732-byte Python script that requires no extra software on the target system (Theori technical write-up).
- Exploitation is deterministic — there is no race condition to win, so the same exploit succeeds reliably on every run (Help Net Security).
- The same exploit works across many distributions and kernel versions without modification (Theori).
- It modifies only the page cache in memory, not the file on disk — so file-integrity monitors such as AIDE or Tripwire will not flag it (Orca Security).
- It leaves no on-disk forensic trace, and Theori notes it can break out of common container isolation if AF_ALG is reachable.

## Who is affected

The vulnerability affects every mainstream Linux distribution shipping a kernel built between 2017 and the availability of the patch. CERT-EU's advisory lists the following distributions as directly verified by the researchers:

- Ubuntu 24.04 LTS — kernel 6.17.0-1007-aws
- Amazon Linux 2023 — kernel 6.18.8-9.213.amzn2023
- Red Hat Enterprise Linux 10.1 — kernel 6.12.0-124.45.1.el10_1
- SUSE Linux Enterprise 16 — kernel 6.12.0-160000.9-default

Openwall Project founder Alexander Peslyak (Solar Designer) independently confirmed on the oss-security mailing list that the public exploit also works on Rocky Linux 9.7. Other distributions running kernels in the affected range — Debian, Arch Linux, Fedora, AlmaLinux, Oracle Linux and many embedded Linux builds — are implicitly affected.

> **Not affected** _(note)_
>
> Per CERT-EU and Ubuntu's security tracker, kernels prior to 4.13 (which predate the 2017 in-place optimisation) and the upcoming Ubuntu 26.04 'Resolute' kernels are not affected.

## Patch status as of 30 April 2026

The upstream fix is mainline Linux commit a664bf3d603d, which reverts the 2017 in-place optimisation. It was committed by Linus Torvalds on 1 April 2026 (CERT-EU; torvalds/linux on GitHub). Distribution rollouts are still in progress.

CERT-EU's snapshot of vendor patch availability on the day after public disclosure was sobering: Ubuntu 20.04 through 24.04, Amazon Linux 2023 and SUSE Linux Enterprise had no fixed kernel package available, and Red Hat's status was unknown. Help Net Security reports that some distributions had been notified in advance and have since shipped packages containing the upstream commit, but coverage is uneven and admins should confirm with their own vendor's security tracker.

## How to mitigate it now

If your distribution has not yet shipped a patched kernel, both Theori and CERT-EU recommend two interim mitigations that block the exploit's first step — opening an AF_ALG socket — without breaking common cryptographic services.

### 1. Blacklist the algif_aead module

CERT-EU's advisory provides this configuration to disable the vulnerable module persistently:

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

> **What this does — and doesn't — break** _(info)_
>
> Per CERT-EU, this workaround does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS or SSH. It may affect applications explicitly configured to use the afalg OpenSSL engine or that bind aead/skcipher/hash sockets directly. You can assess exposure with: lsof | grep AF_ALG.

### 2. Block AF_ALG socket creation via seccomp

For containerised workloads — Docker, Podman, Kubernetes — CERT-EU recommends blocking AF_ALG socket creation in seccomp profiles regardless of patch status. Because the exploit must open an AF_ALG socket as its first step, this measure prevents exploitation even on unpatched host kernels.

## Patching priority

Theori's advisory, echoed by Help Net Security and CERT-EU, recommends that administrators patch in this order:

1. Multi-tenant Linux systems — shared hosts, jump boxes and bastion servers where untrusted users have shell access.
2. CI/CD runners — GitHub Actions self-hosted runners, GitLab runners, Jenkins agents and similar systems that execute code from pull requests.
3. Cloud SaaS platforms running customer-supplied code, including notebooks, sandboxes and serverless platforms backed by container clusters.
4. Kubernetes nodes and other container orchestrators, particularly where container escape would expose other tenants.
5. Standard Linux servers and single-user workstations, which are at lower but non-zero risk.

## How to check if a fix is installed

There is no single universal check, but two practical signals help. First, your distribution's security tracker page for CVE-2026-31431 (Ubuntu, SUSE and Red Hat all maintain one) will indicate the fixed package version for each supported release. Second, on Debian/Ubuntu systems you can compare your running kernel — uname -r — against the 'fixed in' version listed at ubuntu.com/security/CVE-2026-31431; on RHEL-family systems use access.redhat.com/security/cve/CVE-2026-31431.

## Context: how this compares to past Linux LPEs

Linux has weathered several headline LPEs in the last decade. Dirty COW (2016) abused a copy-on-write race to write to read-only memory mappings; Dirty Pipe (2022) abused a flaw in the pipe subsystem to overwrite read-only files. Both required either winning a race condition or hitting specific preconditions, which limited reliability.

Help Net Security and Sysdig both note that Copy Fail is closer to Dirty Pipe in impact but more reliable in execution: a small, deterministic exploit that works the first time on most affected systems. That combination — broad reach, no race, no on-disk trace, container-aware — is why advisories are urging fast action even though the public PoC is small and has been responsibly coordinated with distributions.

> **If you administer Linux fleets** _(tip)_
>
> Even after patching, consider keeping the seccomp AF_ALG block in your default container profile. Very few workloads legitimately use the AF_ALG userspace crypto API, and disabling it removes an entire class of future kernel-crypto LPEs at low operational cost (CERT-EU recommendation).

## Bottom line

CVE-2026-31431 is not a remote-code-execution flaw — an attacker still needs some way to run code on your system as a regular user. But for any environment where that condition is even occasionally met — multi-tenant hosts, CI runners, customer-facing SaaS, Kubernetes clusters — Copy Fail effectively converts an unprivileged foothold into full root, reliably and without leaving disk-level evidence.

Treat this as a high-priority patching event: apply your distribution's kernel update as soon as it is available, deploy the algif_aead and seccomp mitigations in the meantime, and prioritise systems that run untrusted code first.

> **Sources** _(info)_
>
> Theori — copy.fail technical advisory and PoC (github.com/theori-io/copy-fail-CVE-2026-31431). — Linux kernel mainline commit a664bf3d603d (torvalds/linux, 1 Apr 2026). — CERT-EU Security Advisory 2026-005, 'High Vulnerability in the Linux Kernel (Copy Fail)', 30 Apr 2026 (cert.europa.eu/publications/security-advisories/2026-005). — Help Net Security, 'Nine-year-old Linux kernel flaw enables reliable local privilege escalation (CVE-2026-31431)', Zeljka Zorz, 30 Apr 2026. — The Register, 'Linux cryptographic code flaw offers fast route to root', 30 Apr 2026. — Sysdig blog, 'CVE-2026-31431: Copy Fail Linux kernel flaw lets local users gain root in seconds', Michael Clark, 30 Apr 2026. — Orca Security, 'CVE-2026-31431: Linux Copy Fail LPE to Root'. — loginline.com, 'CVE-2026-31431: 732 bytes to become root on (almost) every Linux server'. — Ubuntu Security Tracker (ubuntu.com/security/CVE-2026-31431), SUSE (suse.com/security/cve/CVE-2026-31431) and Red Hat (access.redhat.com/security/cve/CVE-2026-31431). — Openwall oss-security list confirmation by Solar Designer (seclists.org/oss-sec/2026/q2/291).

> **About this article** _(note)_
>
> This report summarises publicly available technical information for awareness and patching purposes. It does not include exploit code or operational guidance for attackers. Always validate fixes against your own distribution's official security tracker before relying on them in production.

---

_Canonical article: [https://brainwavepost.com/article/linux-copy-fail-cve-2026-31431-root-vulnerability](https://brainwavepost.com/article/linux-copy-fail-cve-2026-31431-root-vulnerability) — © BrainWavePost. Educational content; see the article page for full disclaimers._