클라우드플레어의 리눅스 'Copy Fail' 취약점 대응 사례

How Cloudflare responded to the “Copy Fail” Linux vulnerability 2026-05-07 Chris J Arges Sourov Zaman Rian Islam 8 min read On April 29, 2026, a Linux kernel local privilege escalation vulnerability was publicly disclosed under the name "Copy Fail" ( CVE-2026-31431 ). Cloudflare’s Security and Engineering teams began assessing the vulnerability as soon as it was disclosed. We reviewed the exploit technique, evaluated exposure across our infrastructure, and validated that our existing behavioral detections could identify the exploit pattern within minutes. There was no impact to the Cloudflare environment, no customer data was at risk, and no services were disrupted at any point. Read on to learn how our preparedness paid off. Background Our Linux kernel release process Cloudflare operates a global Linux server infrastructure at an immense scale, with datacenters located across 330 cities . We maintain a custom Linux kernel build based on the community's Long-Term Support (LTS) versions to manage updates effectively at this volume. At any given time, we may utilize multiple LTS versions from various series, such as 6.12 or 6.18, which benefit from extended update periods. The community regularly merges and releases security and stability updates which trigger an automated job to generate a new internal kernel build approximately every week. These builds undergo testing in our staging data centers to ensure stability before a global rollout. Following a successful release, the Edge Reboot Release (ERR) pipeline manages a systematic update and reboot of the edge infrastructure on a four-week cycle. Our control plane infrastructure typically adopts the most recent kernel, with reboots scheduled according to specific workload requirements. By the time a CVE becomes public knowledge, the necessary fix has typically been integrated into stable Linux LTS releases for several weeks. Our established procedures ensure that we have already deployed these patches. At the time of the "Copy Fail" disclosure, the majority of our infrastructure was running the 6.12 LTS version, while a subset of machines had begun transitioning to the newer 6.18 LTS release. About the Copy Fail vulnerability It helps to understand the vulnerability before getting to the response story. A comprehensive write-up can be found in the original Xint Code disclosure post. AF_ALG and the kernel crypto API The Linux kernel's internal crypto API manages functions like kTLS and IPsec. Userspace programs access this via the AF_ALG socket family, allowing unprivileged processes to request encryption or decryption. The algif_aead module facilitates this for Authenticated Encryption with Associated Data (AEAD) ciphers. An unprivileged program follows these steps: Opens an AF_ALG socket and binds to an AEAD template. Sets a key and accepts a request socket. Submits input via sendmsg() or splice() . Executes the operation using recvmsg() . The splice() system call is critical here, as it moves data by passing page cache references. Memory mechanics: page cache and in-place crypto The page cache is a shared system cache for file contents. Modifying a page belonging to a setuid binary effectively edits that program for all users until the page is evicted. The crypto API utilizes scatterlists , which are structures linking various memory pages. In 2017, algif_aead was optimized for in-place operations, chaining destination and reference pages together. This design lacked enforcement to prevent algorithms from writing past intended boundaries. The vulnerability: out-of-bounds write When the user executes recvmsg() , the authencesn wrapper in the kernel performs a 4-byte write past the legitimate output region: scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1); By using splice() , an attacker can chain a target file's page cache pages to the scatterlist. The out-of-bounds write then taints the cached file, allowing an attacker to control which file is modified, the offset, and the specific 4 bytes written. This means the attacker can manipulate the following with this exploit: File: Any readable file. Offset: Tunable via assoclen and splice parameters. Value: Controlled via AAD bytes 4-7 in sendmsg() The exploit, step by step The default exploit targets /usr/bin/su , a setuid-root binary present on essentially every distribution. Cache Reference: Open /usr/bin/su as O_RDONLY and read() to populate the page cache. Use splice() on the file descriptor to pass these page cache references into the crypto scatterlist. Setup: Create an AF_ALG socket, bind() to authencesn(hmac(sha256),cbc(aes)) , set a key, and accept a request socket without needing privileges. Write Construction: For each 4-byte shellcode chunk: sendmsg() with AAD bytes 4–7 containing the shellcode. splice() the binary into a pipe then the AF_ALG socket so assoclen + cryptlen targets the desired .text offset. Trigger: recvmsg() initiates decryption. authencesn writes its scratch data to the target offset of /usr/bin/su in the page cache. Although the function returns -EBADMSG , the 4-byte write is now in the global page cache. Execution: Running execve("/usr/bin/su") loads the tainted page cache. Since the binary is setuid-root, the injected shellcode executes with root privileges. The upstream fix ( commit a664bf3d603d ) reverts the 2017 in-place optimization, removing the exploit. How we responded When the vulnerability was disclosed, many workstreams started in parallel: Mapping the blast radius: Our security team worked with kernel engineers to determine which kernel versions were vulnerable and assess the potential exposure. Validating coverage: Security reviewed the exploit technique and confirmed that our existing behavioral detections could identify the exploit pattern during authorized internal validation. Proactive threat hunting: Security began searching for signs that the vulnerability had been exploited before it was publicly known, going back 48 hours in our fleet-wide logs. Engineering a mitigation: Kernel engineers began building a runtime mitigation that would protect the fleet without breaking production services. Continuing software updates : Our engineering teams worked on delivering an updated Linux kernel, which required carefully rebooting and rolling it out across our servers. There was no customer impact at any point during this response. Validating detection coverage One of the first things our security team did was confirm that our existing endpoint detection would catch this exploit. Our servers run behavioral detection that continuously monitors process execution patterns. It doesn't rely on knowing about specific vulnerabilities; it watches for anomalous behavior across the fleet. When our engineers validated the vulnerability internally as part of the response, the detection platform flagged it within minutes. The system linked the entire execution chain—starting at the script interpreter, moving through the kernel’s cryptographic subsystem, and ending at the privilege escalation binary—flagging it as malicious based on fleet-wide behavioral patterns. This happened without a signature update, without a rule change, and without human intervention. Our behavioral detection coverage existed before we wrote any custom logic for this particular Copy File exploit. The confirmation was important because it meant we had coverage before writing a vulnerability-specific rule. Hunting for exploitation While our engineering team moved to a more targeted mitigation, our security investigation had been running since disclosure. This is our standard procedure for any critical vulnerability. Our security team operates on a simple principle for critical vulnerabilities: assume compromise until you can prove otherwise. The investigation started from the assumption that exploitation could have occurred before the vulnerability was public, and we worked systematically to either confirm or rule it out. The exploit le