How Cloudflare responded to the “Copy Fail” Linux vulnerability

Copy Fail: Inside Cloudflare’s Response to the Linux Kernel Flaw

On April 29, 2026, security researchers publicly disclosed "Copy Fail" (CVE-2026-31431), a Linux kernel vulnerability enabling local privilege escalation. Cloudflare's security and engineering teams immediately began assessing the flaw, which affects the kernel's cryptographic subsystem and can be triggered by unprivileged processes.

After a thorough investigation and a staged mitigation rollout, there was no impact to Cloudflare's environment, no customer data was at risk, and no services were disrupted at any point.

The Kernel Release Pipeline That Limited Exposure

Cloudflare operates custom Linux kernels based on community Long-Term Support (LTS) versions across its fleet in more than 330 cities. At any given time, the company may run multiple LTS series—such as 6.12 or 6.18—that benefit from extended update windows.

When the community merges security and stability fixes, an automated job triggers a new internal kernel build roughly every week. These builds go through staging datacenter validation before global rollout. The Edge Reboot Release (ERR) pipeline then handles systematic updates across edge infrastructure on a four-week cycle. Control plane infrastructure typically adopts the newest kernel sooner, with reboots scheduled based on workload requirements.

This process means that by the time a CVE becomes public, the fix has usually been in stable LTS releases for several weeks and already deployed. At the time of the "Copy Fail" disclosure, most infrastructure was on 6.12 LTS, with some machines already transitioning to 6.18.

How the Exploit Works

The flaw sits in algif_aead, a kernel module that lets userspace programs request Authenticated Encryption with Associated Data (AEAD) operations through the AF_ALG socket family. Programs bind to an AEAD template, set a key, then submit data via sendmsg() or splice() before executing the operation with recvmsg().

In 2017, algif_aead was optimized for in-place operations, chaining destination and reference pages in scatterlists without properly enforcing write boundaries. This design flaw allows a 4-byte out-of-bounds write past the legitimate output region when recvmsg() triggers the authencesn wrapper:

scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);

The attack chain works by abusing splice() to pass page cache references into the crypto scatterlist. An attacker can then control which file gets modified, the offset, and the exact 4 bytes written—allowing manipulation of any readable file on the system.

The default target is /usr/bin/su, a setuid-root binary present on virtually every distribution. The exploit caches a reference to it, constructs a write that injects shellcode into its .text section via the out-of-bounds write, then triggers execve("/usr/bin/su") to execute the shellcode with root privileges. Even though recvmsg() returns -EBADMSG, the 4-byte write has already hit the global page cache.

The upstream fix (commit a664bf3d603d) reverts the 2017 in-place optimization, eliminating the vulnerability entirely.

Parallel Response Workstreams

When disclosure happened, several efforts launched simultaneously:

• Blast radius mapping: Security worked with kernel engineers to identify vulnerable kernel versions and assess exposure.
• Detection validation: Security confirmed that existing behavioral detections could identify the exploit pattern during authorized internal testing.
• Threat hunting: Teams searched fleet-wide logs from 48 hours before disclosure for signs of prior exploitation.
• Mitigation engineering: Kernel engineers built a runtime mitigation that blocked the exploit without breaking production services.
• Kernel updates: Engineering prepared a patched kernel build that required careful orchestration of reboots across the fleet.

Behavioral Detection Caught It Without Signatures

One of the first validations was confirming existing endpoint detection would flag the exploit. Cloudflare's servers run behavioral detection that continuously monitors process execution patterns, watching for anomalous behavior rather than matching known vulnerability signatures.

During internal validation—before any custom detection rule was written—the platform flagged the exploit within minutes. It linked the full execution chain from script interpreter through the kernel crypto subsystem to the privilege escalation binary, identifying it as malicious based on fleet-wide behavioral patterns. This happened without a signature update or rule change.

Hunting for Prior Exploitation

Operating on the principle of assuming compromise until proven otherwise, the security team searched for traces of pre-disclosure exploitation. The exploit leaves a distinctive mark in kernel logs when it runs, so investigators searched centralized logging for that signal across 48 hours before the vulnerability was public.

They also pulled access logs for affected systems, reconstructed who connected and what commands they ran, checked system binaries against known-good cryptographic hashes, looked for persistence mechanisms, and audited network connections. Nothing suspicious was found.

Stage One: The Simple Fix Was Too Broad

Because deploying a patched kernel fleet-wide takes time, the team pursued a reboot-free mitigation. The obvious approach was removing the vulnerable algif_aead module and preventing reload—exactly what the researchers' write-up recommends.

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

But that would break legitimate software using the kernel crypto API. Cloudflare needed a more surgical approach.

Stage Two: BPF-LSM Enforcement

Cloudflare had already built a tool for this scenario: bpf-lsm. Rather than removing the module, this tool keeps it loaded for legitimate users while using a BPF Linux Security Module program to deny the socket_bind LSM hook for everything else—completely blocking the exploit's entry point.

A draft of the eBPF program was assembled overnight and made production-ready the following day. The logic is straightforward on every socket_bind call:

1. If the socket family is not AF_ALG, allow it through unchanged.
2. If it's AF_ALG, check the calling binary's path against an allow-list of known legitimate users.
3. If on the allow-list, allow the bind; otherwise, deny it.

To verify mitigation without triggering the exploit, the Copy Fail write-up provides a simple test:

python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));'

On a mitigated machine, that command returns PermissionError: [Errno 1] Operation not permitted (or FileNotFoundError, depending on which mitigation is active) instead of a successful bind.

Staged Rollout Based on Fleet-Wide Visibility

Before enforcing restrictions, the team confirmed that a single known internal service was the only legitimate AF_ALG user. Using prometheus-ebpf-exporter, they hooked the socket() syscall and tracked AF_ALG usage per binary across hundreds of thousands of servers within hours—without kernel changes.

The rollout deliberately proceeded in two stages:

1. Visibility first: Push the ebpf-exporter config gated by salt, and confirm at the metric layer that the known service is effectively the only thing creating AF_ALG sockets.
2. Then enforce: Push the bpf-lsm program behind a separate enforcement gate once visibility confirmed the allow-list is accurate.

In parallel, the upstream backport for the majority LTS line became available, and internal automation built a patched kernel. That kernel went through staging datacenter testing before the fleet-wide reboot process resumed to fully patch all systems.

Post-incident review and hardening plans

While Cloudflare's preparation paid off, the incident exposed areas where the company plans to improve its response capabilities. Three priorities emerged from the post-mortem:

• Mapping kernel-API dependencies. The team will audit how production services depend on kernel subsystems so future exploits can be mitigated quickly without risking service disruption.
• Strengthening runtime mitigation tooling. bpf-lsm proved effective, and Cloudflare wants to make it faster to deploy, with better runbooks and improved logging and visibility into the tool's actions.
• Reducing kernel attack surface. A review of kernel configurations will identify unused modules and features that can be removed from build kernels altogether, proactively shrinking the exposure window.

What the incident showed

"Copy Fail" was an unusual test of Cloudflare's response process. Although the company routinely patches its kernels on a two-week cadence, the vulnerability persisted because a fix that had landed in the mainline kernel a month earlier had not yet been backported to the primary production kernel line. When the backport finally arrived, patched kernels were rolled out across the fleet within hours.

In the interim, bpf-lsm provided a surgical mitigation path that blocked the vulnerable code for non-allow-listed binaries without requiring a reboot. An early attempt to disable the problematic kernel module failed, but that failure occurred in the internal staging environment rather than production. That safe failure was the key that let engineers identify the hidden module dependency.

At the end of the rollout, every machine was protected either by a patched kernel or by a bpf-lsm policy denying execution of the vulnerable path. Cloudflare reports zero customer impact throughout the incident.

The company credits the coordinated response across Security, Engineering, Product, and other teams, along with the responsible disclosure process and the availability of in-kernel visibility tooling, for enabling a swift resolution. The follow-up improvements around dependency mapping, mitigation tooling, and kernel configuration are intended to make the next response faster still.