Linux Copy Fail CVE-2026-31431 Lets Local Users Gain Root

Copy Fail turns AF_ALG memory handling into a privilege boundary failure​

The headline number—732 bytes—is striking, but the useful fact is what that small exploit can accomplish. Theori’s Xint research describes a controlled four-byte write into the Linux kernel’s page cache, usable by an unprivileged local user against a readable file. The researchers report that their compact Python proof of concept can use that capability to modify a privileged executable and obtain root across a broad range of Linux distributions.

Microsoft’s May 1 analysis and the CERT Coordination Center’s vulnerability note corroborate the central mechanism and the availability of the proof of concept. This is a local privilege escalation: the attacker must already be able to execute code on the affected Linux system. Copy Fail does not, by itself, let an unauthenticated person on the internet take over a server.

That prerequisite still leaves many important enterprise scenarios. Microsoft identifies an SSH foothold, malicious CI job execution, and a compromised application container as possible starting points. Each provides a different route to the same boundary: code that should have limited authority attempts to acquire root privileges through the host kernel.

Forkast’s September 20 coverage brought renewed attention to the vulnerability, but September was not its disclosure month. Forkast gives April 22 as a publication date; CERT-EU and CERT/CC identify April 29 as the public disclosure date. Microsoft published its analysis on May 1, while CERT/CC released vulnerability note VU#260001 on May 8. Those dates matter when interpreting early statements about missing patches or the extent of observed exploitation.

The affected interface is AF_ALG, which exposes kernel cryptographic operations to applications. Within it, the algif_aead implementation provides access to authenticated encryption with associated data, or AEAD. Microsoft describes improper memory handling during in-place operations, where an operation reuses source memory for its destination instead of keeping the two separate.

This is a serious implementation failure in a privileged subsystem. It does not establish that the underlying encryption algorithms have been broken, or that every Linux identity and cryptographic operation is inherently untrustworthy. The demonstrated security failure is more specific: an unprivileged process can cause the kernel to modify file-backed memory that the process should not be allowed to alter, then use that modification to cross the local privilege boundary.

The Linux page cache explains why an unchanged disk is insufficient​

Copy Fail combines the affected cryptographic operation with splice(), a Linux system call that can transfer file data by reference rather than first copying it into an independent buffer. In the vulnerable path, references to file-backed page-cache memory reach a destination that the cryptographic operation can write to. The result is the controlled four-byte modification described by the researchers.

The page cache is the kernel’s in-memory representation of file data. That distinction between a file’s cached contents and its persistent contents is central to the vulnerability. An attacker need not obtain normal write permission to the underlying executable if the kernel can instead be induced to alter the bytes that later reads and execution will encounter in memory.

Microsoft and CERT/CC identify a setuid executable such as /usr/bin/su as a possible target. A setuid program can execute with privileges associated with its owner, making corruption of such a program security-sensitive. The proof of concept demonstrates how modification of its cached contents can produce local root access.

CERT/CC supplies an especially important detail: the corrupted page is not marked dirty, the state that would indicate modified contents should be written back to disk. Consequently, the exploit’s page-cache modification does not update the underlying file. The bytes stored persistently can remain unchanged while the active system encounters the corrupted cached representation.

That creates a limitation for integrity checks, but it should not be exaggerated into universal invisibility. A check examining the underlying persistent file can find the original contents; a read served through the modified cache can encounter different contents. Whether a particular monitoring tool notices the discrepancy depends on what it observes. The supported conclusion is that file-integrity monitoring alone cannot establish that Copy Fail was not used.

The exploit’s determinism is equally relevant. Microsoft and CERT/CC describe it as independent of a race condition or a narrow timing window. Administrators therefore should not treat a constrained execution environment, or an assumption that kernel exploits are unreliable, as a substitute for remediation. At the same time, “732 bytes” describes a particular proof of concept—not a universal exploit signature, an affected-system test, or a measure of how much evidence an intrusion will leave.

Copy Fail exposure follows the running kernel, not the distribution label​

Microsoft identifies Ubuntu, Amazon Linux, Red Hat Enterprise Linux, and SUSE among affected distribution families, with Debian, Fedora, and Arch Linux also potentially affected. The practical condition is narrower than “a computer runs Linux”: the machine must have a vulnerable kernel implementation and an available, initialized affected interface. A distribution name by itself does not establish whether an individual system remains exposed.

CERT-EU’s April advisory records four configurations that the researchers directly verified. These are useful concrete examples of affected systems, not a complete vulnerability inventory and not a list of current fixed-package versions.

The age of that evidence is important. CERT-EU’s April 30 status table said fixes were unavailable for several distribution families at that time. It would be incorrect to carry that statement into September as a current patch advisory. Indeed, the SUSE statement included in CERT/CC’s May 8 note already says that affected SUSE and openSUSE distributions had received kernel updates and kernel live patches.

The available advisories do not provide a complete, current September fixed-build matrix for every distribution. Accordingly, there is no defensible single minimum version to prescribe across Ubuntu, RHEL, Amazon Linux, SUSE, and custom kernels. The relevant check is whether the running kernel has the vendor’s fix for CVE-2026-31431, not merely whether a package name looks recent or belongs to one of the listed distribution releases.

Containers make that inventory more consequential. Microsoft warns that shared kernel and page-cache behavior can allow exploitation from a compromised container to affect the node or other containers. For a Kubernetes administrator, the exposure assessment therefore belongs at the worker-node kernel as well as at the application workload. Replacing an application image without addressing a vulnerable host kernel does not address the documented flaw.

Virtual machines have a different boundary. CERT/CC explicitly says that exploiting Copy Fail inside a conventional VM or microVM does not directly provide a virtualization escape into the host kernel. A vulnerable Linux guest can still be compromised internally, but that is distinct from taking over its hypervisor or neighboring guests. For Windows administrators managing Linux workloads, this is a Linux-kernel remediation task; the evidence does not establish a Windows-kernel vulnerability, and Microsoft Defender’s involvement should not be mistaken for one.

Kernel updates fix Copy Fail; interface restrictions provide interim containment​

CERT-EU identifies upstream commit a664bf3d603d, committed on April 1, 2026, as the fix. It reverts the vulnerable in-place optimization and restores an out-of-place operation, separating the source and destination buffers. That change addresses the memory-handling mechanism that makes the page-cache write possible.

Distribution kernel updates are the preferred remediation. The upstream commit identifies the change vendors need to incorporate, but it is not itself evidence that any particular deployed distribution package contains the fix. CERT/CC recommends updating the distribution’s kernel package; Microsoft likewise recommends patching the kernel or blocking AF_ALG socket creation.

A useful remediation record should capture the affected machine or node, its running kernel, the applicable vendor fix, and whether that fix is active. Where a vendor supports kernel live patching, its coverage is relevant; where a replacement kernel must be activated, installing a package alone is not the end state. The precise fixed package and activation procedure vary by distribution and are not established for every platform in the available evidence.

Disabling loadable algif_aead requires both prevention and removal​

For systems where algif_aead is a loadable module, CERT/CC documents this temporary workaround:

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

These are administrative changes, and their compatibility effect should be assessed before deployment. They disable the affected interface rather than repair its implementation. Applications that explicitly depend on AF_ALG cryptographic operations may be affected.

The two commands serve different purposes:

1. The first writes a module-install rule intended to prevent algif_aead from being loaded through the configured module-loading mechanism.
2. The second attempts to remove algif_aead if it is already loaded.
3. The intended mitigation state is that the affected module is inactive and cannot be loaded through that configured path.

The distinction between preventing a future load and removing an existing module is operationally important. Writing the configuration file does not itself remove already active functionality. Also, CERT/CC’s command redirects the removal command’s error output to /dev/null; a silent terminal therefore should not be recorded as proof that unloading succeeded. If removal fails, the live-system portion of the workaround has not been demonstrated.

CERT-EU says the workaround does not affect ordinary use of dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH. Its compatibility warning concerns applications explicitly configured to use the affected AF_ALG interfaces, including relevant engine or direct socket use. That is a much more specific impact than “disabling Linux encryption.”

CERT-EU suggests investigating AF_ALG use with:

lsof | grep AF_ALG

This can help identify visible use when assessing compatibility. It should not be elevated into a complete exposure or application-compatibility test: the advisory offers it as an investigation aid, not as proof that no workload will ever need the interface.

Built-in algif_aead needs a boot-time control​

A module-removal command cannot unload functionality compiled directly into the kernel. For that configuration, CERT/CC documents a different workaround: add the following kernel boot parameter and reboot.

initcall_blacklist=algif_aead_init

The parameter prevents the affected initialization function from running at boot. Its effect therefore begins after the changed boot configuration is used, not when the text is first entered into a configuration file.

CERT/CC names GRUB, systemd-boot, and grubby as possible boot-configuration paths. Their procedures differ, so a universal edit command would be unsafe. The established action is to add the exact parameter through the system’s actual boot-management mechanism, then reboot and confirm that the intended configuration took effect.

This workaround carries the same broad compatibility consideration: software deliberately using the affected kernel cryptographic interface may stop working as expected. The advisories do not establish a universal rollback procedure. Removing a restriction before the kernel fix is active would restore the vulnerable path, so compatibility recovery and security remediation have to be coordinated rather than treated as separate tasks.

AF_ALG socket restrictions are especially relevant to containers and CI​

CERT/CC recommends restricting creation of AF_ALG sockets through seccomp, AppArmor, or eBPF-based enforcement. AF_ALG is address family 38. CERT-EU recommends socket-creation restrictions for containerized workloads and pipelines, including Docker, Podman, and Kubernetes environments.

The protective mechanism is straightforward: the documented exploit needs to open an AF_ALG socket. Denying that operation removes a required entry point even where the kernel has not yet been patched. This is more directly connected to the vulnerability than network isolation, because Copy Fail is a local operation and does not need an external network connection once an attacker can execute code.

There is no single policy snippet in the available evidence that safely covers every runtime and policy system. Seccomp, AppArmor, and eBPF enforcement are alternatives with different deployment mechanisms. The common requirement is to deny the relevant socket-creation path for the workloads being protected, while testing compatibility with applications that intentionally use AF_ALG.

Scope remains essential. A restriction applied to one container protects that workload’s access path; it should not be recorded as a host-wide fix or assumed to cover unrelated containers. Kernel remediation addresses the vulnerable implementation across the host. Workload policy supplies an additional boundary around who can reach it.

Microsoft Defender can help find Copy Fail, but cannot certify a clean disk​

Microsoft’s May 1 research publication lists coverage across Microsoft Defender products. Defender for Endpoint has a detection described as possible CVE-2026-31431 exploitation, while Defender for Cloud lists a potential Copy Fail exploitation detection. Microsoft Defender Vulnerability Management also surfaces devices that may be vulnerable.

The published detection names include:

• Exploit:Linux/CopyFailExpDl.A
• Exploit:Python/CopyFail.A
• Exploit:Linux/CVE-2026-31431.A
• Behavior:Linux/CVE-2026-31431

These names give security teams concrete terms to recognize in product telemetry and incident records. They are Microsoft’s stated coverage, not an independent measurement of detection success. The publication does not establish that every possible exploitation variant will be detected or that absence of an alert proves absence of compromise.

Microsoft’s observations also need their original date attached. On May 1, its researchers described active exploitation as limited and primarily observed in proof-of-concept testing, while warning of increased attacker interest and noting the vulnerability’s addition to CISA’s Known Exploited Vulnerabilities catalog. That is useful historical context; it is not a current September measurement of attack prevalence.

For incident response, the page-cache mechanism changes how evidence should be weighed. An unchanged on-disk executable does not contradict a possible exploitation alert. Process execution, the attacker’s initial foothold, container activity, kernel exposure, and privilege changes are relevant parts of the investigation. This is a practical inference from the documented mechanism: the evidence may live in execution behavior even when the persistent target file remains original.

Microsoft recommends treating container remote-code execution as potential host compromise in this context and enforcing rapid node recycling after compromise indicators. “Potential” is important: a compromised container is not proof that Copy Fail succeeded. But when a vulnerable shared kernel is involved, restricting an investigation to the application container can miss the documented possibility of broader node impact.

Patching and incident response answer different questions. A fixed kernel removes the vulnerable path going forward; it does not, by itself, establish what an attacker did before the fix. Conversely, the existence of in-memory corruption does not prove that an entire attack leaves no persistent evidence. Claims about the exploit’s initial write should not be expanded into claims about every subsequent action available to a root-level attacker.

What Copy Fail means for Linux hosts under your care​

Prioritize systems that execute code from users or workloads you do not fully trust, and close remediation against the active kernel rather than against a distribution name. Kubernetes workers, shared Linux servers, and CI/CD runners deserve particular attention because the local-code-execution prerequisite can already be part of their normal operating model. For a single-purpose Linux guest with tightly controlled execution, the same flaw still warrants fixing, but its exposure path differs from that of a shared build node.

The decision should combine three pieces of evidence: whether the kernel contains the fix, whether the affected interface is reachable, and whether there are indicators that someone attempted or achieved exploitation. Those are separate questions. A blocked interface is an interim control, a patched kernel is remediation, and an investigated alert is an incident-response outcome.

• Record the running kernel and its vendor-confirmed CVE-2026-31431 fix status for each relevant Linux host or node; do not use the April affected-build examples as a current patch matrix.
• Apply the distribution’s kernel fix where available, and confirm that the fix is active rather than merely downloaded or installed.
• If patching must wait, use the workaround appropriate to loadable or built-in algif_aead, with application compatibility and successful activation explicitly checked.
• Restrict AF_ALG socket creation for containers and CI workloads that do not need it, while preserving the distinction between workload policy and host-wide remediation.
• Investigate Copy Fail detections using execution and host context, and do not dismiss them solely because the persistent copy of a targeted executable has an unchanged hash.
• Keep container and VM boundaries separate: Copy Fail can threaten a shared container host, but CERT/CC does not identify it as a direct escape from a conventionally isolated VM into its hypervisor.

Copy Fail’s lasting lesson is a concrete one: a file can remain unchanged on disk while the running system consumes an attacker-modified cached representation of it. The documented response is equally concrete—activate the kernel fix, restrict the vulnerable interface where necessary, and investigate suspected exploitation beyond static file checks. For administrators responsible for shared Linux infrastructure, the meaningful next milestone is a fleet record showing that the vulnerable path is fixed or effectively blocked, with suspected compromises handled separately from routine patch deployment.