CVE-2026-31431: Copy Fail - Fix it Now! — Hardcore Engineering [Skip to main content](#main) [![<|$ENG](/static/hc-eng-logo.svg)](/) [HOME](/) [ARTICLES](/articles) [ABOUT](/about) CMD: 0 // CLK: 0 // KEY: 0 // May 02, 2026 / by Stephan Schielke / slop-free guarantee / [llm.md](/articles/copy-fail-cve-2026-31431-patch-and-automate.md "View as Markdown") # CVE-2026-31431: Copy Fail - Fix it Now! Here is how to check, patch, reboot & verify [linux](/articles?tag=linux) [security](/articles?tag=security) [devops](/articles?tag=devops) ![CVE-2026-31431: Copy Fail - Fix it Now!](/static/images/cve-copy-fail-article-cover.webp) FFS. D1r7y effing b4st4rd5 *(pardon my French)* pulling off an irresponsible marketing stunt screwing over millions! I mean, really? Some "security researchers" *(which I will not name or link since they do not deserve the backlink)*, published a critical 0-day Linux kernel vulnerability *(now with live exploits!)* affecting all Linux kernels since 2017 *(uff)* before any patches were rolled out by distro maintainers who did not get notified *(oh 'cmon)*, while coincidentally launching a brand new security product *(MFers)*. Well, here is a guide with tools *(aimed at Ubuntu systems)* on how to secure yourself quickly *(and in a follow-up I'll show you how to set up proactive measures and automate the process with LLM agents)*. Vulnerability Summary * CVE-2026-31431 ("Copy Fail") * CVSS 7.8 (HIGH) ([NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2026-31431)) * CWE-669: Incorrect Resource Transfer Between Spheres * Impact: Local Privilege Escalation + Container Escape * Introduced: Kernel 4.14 (2017), `commit 72548b093ee3` * Fixed in: 6.18.22, 6.19.12, 7.0 ([fix commit](https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5)) * Researcher: Mr. Reckless ([and his shitty product](https://copy.fail/)) How does the saying go? `"There is no bad marketing"`? Well, in my world there is. And I hope your names as security researchers and the name of your company will forever be tainted and I wish for your bloody new product to fail miserably. Disclosing a vulnerability of that magnitude *(we are talking every other server on the planet here)* is highly praised *(even profitable)*, and usually a noble endeavor **after** patches have been rolled out, not before and with a freaking instruction set on howto exploit the issue, endangering actual people's lives worldwide, while simultaneously drawing the anger of all sysadmins on the planet, just to promote your shit. Well, done you! Mother would be proud! With that out of the way... here is: * how to check if you are affected * how to defuse the exploit * how to check if a patch for your system is available yet * how to patch your system *(once patches have been rolled out)* to get you out of the line of fire. *I'm also assembling some further recommendations that will help you secure your systems for similar 0-day events, and offer some advanced (and experimental) agent setup that will act as your personal and automated mini-sysadmin taking care of the last 20% of manual intervention, guarding your machines 24/7.* ## Get Out of the Line of Fire This vulnerability is especially high risk for any machine that: * Runs containers or VMs (page cache is shared with the host kernel; a compromised container means a [compromised host and cross-tenant escape](https://orca.security/resources/blog/cve-2026-31431-linux-kernel-copy-fail-privilege-escalation/)) * Kubernetes clusters (pod-to-node escalation; `RuntimeDefault` seccomp does NOT block AF\_ALG sockets) * CI/CD runners (GitHub Actions self-hosted runners, GitLab runners, Jenkins agents: anything executing untrusted PR code as a regular user becomes root on the runner) * Multi-tenant / shared shell hosts (dev boxes, jump hosts, university servers: any user with shell access becomes root) * Cloud SaaS running user code (notebook hosts, agent sandboxes, serverless functions, any tenant-supplied container or script) * VPS with SSH access (if you give anyone an SSH account, *even a locked-down one*, they can escalate) * Machines with full-disk encryption (if the screen is locked and someone has local code execution via USB, evil maid, or compromised service, they bypass the login screen entirely) ### Step 1: Check If You Are Affected Run `uname --kernel-releasequick copy` on your machine and paste the output below to check instantly: Check The affected kernel range is 4.14.0 through 6.18.21 and 6.19.0 through 6.19.11. Vulnerability is patched in 6.18.22, 6.19.12, and 7.0.0+. If the `algif_aead` module is loaded, you're actively exposed: ```bash # Check if the vulnerable module is loaded lsmod | grep -q algif_aead && echo "Vulnerable module is loaded - Machine exploitable" || echo "Vulnerable module unloaded - Machine not exploitable" ``` ```bash # Check if the module is available on disk (even if not currently loaded) modinfo algif_aead 2>/dev/null && echo "Module available - Could be loaded on demand, blacklist recommended" || echo "Module not found - Not exploitable via this CVE" ``` ### Step 2: Diffuse the Exploit (Blacklist the Module) Do this now, regardless of whether a patch for your distro exists yet or not. Blacklist the module to prevent it from being loaded at all. This is the [mitigation recommended by researchers](https://seclists.org/oss-sec/2026/q2/281) and by [SUSE's advisory](https://www.suse.com/security/cve/CVE-2026-31431.html): sudo (recommended) ```bash # blacklist the vulnerable module echo "install algif_aead /bin/false" \ | sudo tee /etc/modprobe.d/cve-2026-31431.conf \ && echo "Blacklist written" \ || { echo "FAILED to write blacklist"; exit 1; } # unload module if currently loaded sudo rmmod algif_aead 2>/dev/null \ && echo "Module unloaded" \ || echo "Module was not loaded (OK)" ``` root ```bash # blacklist the vulnerable module echo "install algif_aead /bin/false" \ > /etc/modprobe.d/cve-2026-31431.conf \ && echo "Blacklist written" \ || { echo "FAILED to write blacklist"; exit 1; } # unload module if currently loaded rmmod algif_aead 2>/dev/null \ && echo "Module unloaded" \ || echo "Module was not loaded (OK)" ``` This tells `modprobe` to run `/bin/false` instead of loading the module *(which does nothing and exits with an error)*, and `rmmod` unloads the module *(if it is currently loaded)*. This survives reboots because the `.conf` file in `/etc/modprobe.d/` is persistent. #### Does this break anything? The vast majority of systems should not see a degradation in functionality. Most encryption-dependent tools and functionality like dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, SSH: none of these go through AF\_ALG. *"Well, then what the hell is it good for or needed and enabled in the first place?"* you might ask. It *may* affect userspace specifically configured to use the `afalg` OpenSSL engine. If in doubt, check with `lsof | grep AF_ALG quick copy` to see if there are any open files making use of the module, right now. #### Double check the mitigation worked Confirm the blacklisting worked: ```bash # Verify the module can no longer be loaded modinfo algif_aead 2>/dev/null && echo "Module still available - blacklist may not be active until reboot" || echo "Module not found - mitigation confirmed" ``` Reboot your machine if you see `"Blacklist may not be active until reboot"` then we'll meet again in a bit. Otherwise: *"Phew. We are OK for now. But just OK and not fully out of the woods yet."* ### Step 3: Check If a Patch Is Available The kernel mainline has long been fixed (by commit [`a664bf3d603d`](https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5)), and the fix is available in kernels starting from 6.18.22+, 6.19.12+, and 7.0.0+. But your distro needs to backport and package it first for you to install via a normal upgrade *(That's why we are in this whole mess)*. Check: via apt ```bash # Check if a patched kernel is available sudo apt update apt list --upgradable 2>/dev/null | grep linux ``` via Ubuntu Pro ```bash # Check the CVE fix status directly pro fix CVE-2026-31431 --dry-run # Don't worry if you don't have the `pro` cli. Use `apt`. ``` Patch Status: Ubuntu 24.04 LTS (Noble) As of **2026-05-02T08:33:27Z**, no patched `linux` kernel package has been released for Ubuntu 24.04 LTS (Noble). Canonical has shipped a `kmod` mitigation package (`31+20240202-2ubuntu7.2`) that blacklists the module automatically, but the actual kernel fix remains listed as "Affected" on the [Ubuntu security tracker](https://ubuntu.com/security/CVE-2026-31431). The same applies to Jammy (22.04), Focal (20.04), and all other supported releases. Only Ubuntu 26.04 LTS (Resolute) ships unaffected. See [Canonical's advisory](https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available) for the latest status. #### Curious about Ubuntu Pro? In a follow-up article I'll cover [Ubuntu Pro](https://ubuntu.com/pro) in more detail. The `tl;dr` is it's free for personal use on up to 5 machines and enables [Expanded Security Maintenance](https://ubuntu.com/security/esm) *(10-year security patches for Main + Universe)* and [Canonical Livepatch](https://ubuntu.com/security/livepatch) *(runtime kernel patches without rebooting)*. ```plaintext ~# pro fix CVE-2026-31431 CVE-2026-31431: kmod update - https://ubuntu.com/security/CVE-2026-31431 1 affected source package is installed: linux (1/1) linux: Sorry, no fix is available yet. 1 package is still affected: linux ✘ CVE-2026-31431 is not resolved. ``` "Sorry, no fix is available yet." is what you *(by now hopefully not anymore)* will see in the first hours *(or days)* after a disclosure like this one, while the build servers are churning through kernel compiles. That's why the module blacklist is critical *(while we wait...)*. ### Step 4: Patch Your System Once your distro ships the fix: via apt ```bash # Update, upgrade, reboot sudo apt update \ && sudo apt upgrade -y \ && echo "Upgrade complete - rebooting..." \ && sudo reboot ``` via Ubuntu Pro ```bash # Apply the CVE fix directly sudo pro fix CVE-2026-31431 ``` After reboot, verify you're on the patched kernel: ```bash # Confirm new kernel version echo "Running kernel: $(uname -r)" ``` Paste the output here to verify the new kernel is patched: Verify Then remove the module blacklist *(the kernel fix makes it safe again)*: ```bash # Remove blacklist if it exists ls /etc/modprobe.d/cve-2026-31431.conf 2>/dev/null \ && sudo rm /etc/modprobe.d/cve-2026-31431.conf \ && echo "Blacklist removed - module can load safely now" \ || echo "No blacklist file found - nothing to remove" ``` You're out of the line of fire. Breathe. Now let's understand what we just defused. ## The Vulnerability: Copy Fail [![Hostinger warning email about CVE-2026-31431 Linux kernel vulnerability](/static/images/hostinger-email-cve-2026-31431.png)](https://www.hostinger.com/uk?REFERRALCODE=OI9STEPHSJJS) Very early warning from my Hosting Provider. Thumbs up [Hostinger](https://www.hostinger.com/uk?REFERRALCODE=OI9STEPHSJJS)! The Linux kernel has a module called `algif_aead` that lets regular programs *(not just the kernel itself)* use the kernel's built-in [encryption functions](https://xint.io/blog/copy-fail-linux-distributions). That's normally fine and just like a library anyone can call. The problem is how data gets passed between a program and this module. When a program sends a file to the encryption module, the kernel uses a shortcut called [`splice()`](https://man7.org/linux/man-pages/man2/splice.2.html) that passes the file's data by reference instead of making a copy, which is slightly faster and more memory efficient since you don't have to, well, make a copy of it. An ["optimization" added in 2017](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3) made the encryption module read and write to the same memory location (the original file's cached data in RAM). During decryption, the module writes 4 bytes of bookkeeping data back into that shared memory. Those 4 bytes land directly on top of the cached file content *(Ouch)*. ### Why 4 bytes is enough Linux keeps frequently accessed files in a page cache (a copy in RAM of what's on disk) so your system doesn't have to go the long route of hitting the drive every time a program runs. When you type `sudo`, the kernel doesn't read `/usr/bin/sudo` from disk; it runs the cached version from RAM, which is awesome *(in any case but allowing an unprivileged program to overwrite that cache)*. It's straight forward: With those 4-bytes space the exploit is able to corrupt those cached pages. An unprivileged user *(yep, absolutely any user allowed to run any program)* can then alter the in-memory copy of programs like `/usr/bin/su` or `/usr/bin/sudo`. By carefully corrupting the right bytes, the attacker modifies what those programs do when they execute. The result: any regular user can obtain root privileges. What makes this especially nasty: * The original program file on disk is never modified, so file integrity checks like `debsums` or `rpm -V` won't detect it * The corruption happens even when the decryption fails since the 4-byte change persists (in cache) before the error check kicks in. * An attacker can repeat the process however many times needed to corrupt different offsets, gradually rewriting more and more of the cached program * The entire exploit fits in a 732-byte Python script *(which I'm not gonna link since I'm still mad about how the disclosure was done, fully fucking equipped with a working exploit)* ### What's affected The bug was [introduced in kernel 4.14](https://seclists.org/oss-sec/2026/q2/281) back in 2017 and has been lurking there for nine years. That means: * Every major Linux distribution (Ubuntu, Debian, RHEL, Amazon Linux, SUSE, Fedora, Arch, and everything in between) * Every container and VM (Docker, Podman, LXC, KVM guests all share the host kernel's page cache; a compromised container = a compromised host. That includes all your random ass MCP docker containers not using the [Docker MCP Gateway](https://docs.docker.com/ai/mcp-catalog-and-toolkit/faqs/)) * Every cloud instance running a kernel from 2017 or later *(which is essentially all of them)* * Only requirement: the attacker needs local code execution like an SSH account, a container shell, a CI runner, a Jupyter notebook, basically any way to run a script. For the full technical deep-dive, the original research team has the best resources (obviously) but screw those guys. Instead if you wanna dive deeper, see: * [Tenable FAQ](https://www.tenable.com/cve/CVE-2026-31431) * [SecurityWeek coverage](https://www.securityweek.com/copy-fail-logic-flaw-in-linux-kernel-enables-system-takeover/) * [The kernel mailing list announcement](https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u) * [Ars Technica called it "the most severe Linux threat in years"](https://arstechnica.com/security/2026/04/as-the-most-severe-linux-threat-in-years-surfaces-the-world-scrambles/) You're good for now. But this 0-day once more demonstrated that no system is safe, and decades old undiscovered bugs are just waiting to be discovered by our new AI friends. Manually patching every time a CVE drops is not a strategy, it's a hassle and massive liability. I can't promise you full security *(no one can)*, but in Part 2 I'll cover how to set up [Ubuntu Pro](https://ubuntu.com/pro), automate the upgrade process with `unattended-upgrades` and `cron/anacron`. I also help you automate these last pesky 20% that usually requires manual intervention but can be solved by employing some AI friends that work on our side and in our team. Since, who knows, the next disclosed 0-day might not even come with a patch at all. [← Back to all articles](/articles) [Markdown Version](/articles/copy-fail-cve-2026-31431-patch-and-automate.md) keyboard\_command\_key /search for stuff Send a prompt to my LLMs /summarize a page Open a chat Use a /command Send a /dm to my phone Ask the /chat assistant Smash your head against the keyboard Hire me /search for stuff ... CTRL+K