CVE-2026-31431: Hardening Linux Against Copy Fail - Patching, Containment, and Defense-in-Depth
CVE-2026-31431 Copy Fail - Closing the Door: Patching, Mitigations, Hardening, and Vulnerability Chaining
Parts 1 through 3 established what Copy Fail is, how it works mechanically, and how to detect it. Part 4 is the operational close: verified patch procedures for every affected distribution, the interim mitigation that requires no reboot for most environments, seccomp and AppArmor policy to harden the AF_ALG attack surface, Kubernetes-specific controls, vulnerability chaining risks with CVE-2026-43284 (Dirty Frag), and the long-term hardening principles that prevent the next Copy Fail from being equally severe.
Remediation Priority Framework
Not every host in a fleet has the same exposure level. The following framework assigns remediation priority based on the combination of kernel patch status, host role, and network reachability. Apply patches in this order to reduce overall risk fastest.
Per-Distribution Patch Verification
Applying the patch is step one. Verifying the patch is step two. The following procedures confirm the running kernel contains the fix for each major distribution. All commands should be run on the target host after the update and reboot cycle is complete.
Ubuntu
RHEL / AlmaLinux / Rocky Linux
Amazon Linux 2023
Windows WSL2
Interim Mitigation - algif_aead Module Blacklist
If kernel patching cannot be completed within the required window - due to change management cycles, maintenance windows, or operational constraints - the algif_aead module can be blacklisted to remove the exploit path entirely. This mitigation does not require a kernel update, but it does require a reboot to take effect (or alternatively, an immediate module unload if the module is not currently in use).
Compatibility Assessment Before Applying
The blacklist is safe for the vast majority of production environments because algif_aead is rarely used directly. Verify against your environment before applying:
| Technology | Uses algif_aead | Impact of Blacklist |
|---|---|---|
| dm-crypt / LUKS disk encryption | No | None - dm-crypt uses its own kernel crypto API path, not AF_ALG |
| OpenSSL (default build) | No | None - default OpenSSL uses userspace crypto, not AF_ALG |
| GnuTLS (default build) | No | None - same as OpenSSL; AF_ALG backend is opt-in, not default |
| OpenSSH | No | None - SSH uses userspace crypto implementations |
| kTLS (kernel TLS) | No | None - kTLS uses tls.ko, not algif_aead |
| IPsec (strongSwan / Libreswan) | No | None - IPsec uses xfrm subsystem, not AF_ALG userspace sockets |
| WireGuard | No | None - WireGuard uses its own internal Zinc crypto library |
| Applications explicitly using AF_ALG AEAD sockets | Yes | AEAD operations via AF_ALG will fail - rare in production web or app stacks |
lsmod | grep algif_aead. If the module is not loaded, nothing is currently using it. If it is loaded, check the "Used by" count in the output. A count of zero means it is loaded but idle. To confirm which processes have AF_ALG sockets open, run ss -a | grep AF_ALG or lsof | grep AF_ALG.
Applying the Blacklist
Reverting the Mitigation After Patching
Long-Term Hardening - Restricting the AF_ALG Attack Surface
Patching removes CVE-2026-31431 specifically. Restricting the AF_ALG interface for workloads that do not need it removes the entire attack surface class. If a future vulnerability in algif_aead, algif_hash, algif_skcipher, or any other AF_ALG module is discovered, these controls will mitigate it without requiring an emergency patch cycle.
seccomp Profile - Block AF_ALG Socket Creation
A seccomp profile that restricts socket() calls with AF_ALG (family 38) prevents any process running under that profile from opening an AF_ALG socket, regardless of kernel patch status. This is the most robust long-term control.
AppArmor Profile - Deny AF_ALG for Specific Applications
Kubernetes SecurityContext - Per-Pod and Cluster-Wide Controls
RuntimeDefault seccomp profile is provided by the container runtime (containerd or CRI-O) and blocks a broad set of dangerous syscalls including socket(AF_ALG, ...) in most configurations. However, do not assume it blocks AF_ALG in all runtime versions - test with a probe before relying on it. The Localhost profile with an explicit AF_ALG-blocking rule is the verified path.
Vulnerability Chaining - CVE-2026-43284 (Dirty Frag)
Copy Fail was not the only vulnerability discovered in the algif_aead module during the security audit its disclosure triggered. CVE-2026-43284, disclosed in late May 2026 and nicknamed Dirty Frag, is a separate bug in the same kernel subsystem. Understanding how they relate affects patch prioritization and hardening scope.
Root cause: the 2017 optimization commit collapsing req->src and req->dst into a single scatterlist, allowing the authencesn algorithm to write into the page cache via its scratch write path. Fixed by commit a664bf3d603d which restores separate src/dst scatterlists.
Root cause: a separate memory handling error in algif_aead's recvmsg path when processing fragmented scatterlists. The bug allows a different class of page cache modification under specific conditions. Separate patch required - the Copy Fail fix does not cover Dirty Frag.
| CVE-2026-31431 (Copy Fail) | CVE-2026-43284 (Dirty Frag) | |
|---|---|---|
| Affected module | algif_aead |
algif_aead |
| Vulnerable function | algif_aead_sendmsg (via authencesn scratch) |
algif_aead_recvmsg (fragmented scatterlist) |
| Root cause commit | 72548b093ee3 (2017) |
Separate commit in recvmsg path |
| Fix commit | a664bf3d603d |
Separate patch (check vendor advisory) |
| Same patch covers both | No - separate patches required | No - separate patches required |
| algif_aead blacklist covers both | Yes | Yes - blacklisting the module removes both exploit paths |
algif_aead module fully remediated, verify separately that the Dirty Frag patch is also included in your running kernel. Check your vendor's advisory for CVE-2026-43284 specifically. The algif_aead blacklist mitigation covers both during the interim period.
Chaining Copy Fail with Application Vulnerabilities
Copy Fail requires a local foothold - an existing shell or code execution as an unprivileged user. This makes it the second stage in an attack chain, not a standalone remote exploit. The vulnerabilities it chains with most effectively are those that grant initial code execution on a shared Linux host:
An RCE vulnerability in a web application (deserialization, SSTI, command injection) provides a shell as www-data or another service account. Copy Fail immediately escalates that shell to root. The application-level vulnerability that seemed low-severity in isolation becomes a full server compromise.
A malicious npm, pip, or gem package executes arbitrary code during installation or at runtime. If the host kernel is unpatched, the package payload can include the Copy Fail script and immediately escalate to root in the same process. Dependency confusion and typosquatting attacks become LPE vehicles.
A stolen or brute-forced SSH credential provides initial unprivileged shell access. Copy Fail converts that access to root in under five seconds, before any analyst reviewing the authentication log has had time to respond to the initial login alert.
Risk Assessment - Final Scoring
The following assessment synthesizes the full picture from all four parts of this series into a final operational risk score that accounts for factors the CVSS base score does not capture.
| Risk Factor | Assessment | Influence on Operational Risk |
|---|---|---|
| CVSS 3.1 Base Score | 7.8 High | Baseline. Local attack vector limits the theoretical maximum score. |
| Exploit maturity | Weaponized, public, day-zero | A deterministic public exploit released simultaneously with disclosure eliminates the triage window. Risk multiplier: very high. |
| CISA KEV listing | Confirmed active exploitation | Not a theoretical risk. Real attacks have occurred within 48 hours of disclosure. |
| Cross-distro portability | Universal (all major Linux distros) | An attacker does not need to know the target distribution. The same exploit works everywhere. Reduces operational expertise required by threat actors. |
| Stealth characteristics | In-memory only, FIM-invisible | Standard file-integrity monitoring and most EDR file-watching controls are blind. Detection requires behavioral monitoring, which is less universally deployed. |
| Exposure years before disclosure | ~9 years | Maximum possible silent exploitation window. Cannot rule out prior knowledge or exploitation by sophisticated actors before public disclosure. |
| Blast radius in cloud and container environments | Node-level and cluster-wide | Kubernetes environments can translate one compromised pod into a compromised cluster node and credential access to all co-located pods. |
| Patch availability | Full patch available | All major distributions have released patched kernels. Risk reduces significantly with patching. Interim mitigation closes the attack surface immediately. |
| Overall operational risk | Critical | CVSS 7.8 significantly understates the true risk when exploit maturity, cross-distro universality, stealth, and cloud blast radius are factored in. |
Remediation Action Plan - Consolidated Checklist
Deploy auditd rules for AF_ALG socket detection on all Linux hosts. Identify P0 hosts. Apply the algif_aead interim mitigation on any host that cannot be rebooted for a kernel update within 24 hours. Alert on any existing AF_ALG activity in logs going back 30 days.
Complete kernel patching across P0 and P1 hosts with reboot. Verify patch with uname -r and vendor changelog confirmation. Update Kubernetes node images to patched versions and recycle nodes. Apply the May 2026 Windows Patch Tuesday update to all WSL2 hosts. Remove interim mitigations after patch confirmation.
Deploy seccomp profiles blocking AF_ALG socket creation for all container workloads that do not explicitly require it. Implement Kyverno or OPA policies requiring seccomp profiles on all pods cluster-wide. Enable kernel live patching for critical infrastructure to reduce future LPE patch lag. Patch CVE-2026-43284 (Dirty Frag) separately.
Series Summary - What Copy Fail Taught Us
CVE-2026-31431 is a case study in how vulnerability risk diverges from CVSS scoring when exploit maturity, stealth properties, and environmental blast radius are considered together. A CVSS 7.8 that requires local access sounds manageable. A deterministic, 732-byte, cross-distro Python script that was publicly available before most defenders had finished reading the disclosure, confirmed in active exploitation within 48 hours, and invisible to every file-integrity monitoring tool deployed across the Linux ecosystem is something qualitatively different.
The nine-year exposure window reflects a deeper truth about kernel security: subtle behavioral dependencies between optimization commits and algorithm implementations are exactly the class of issue that standard review processes miss. The right response is not just patching this specific bug - it is treating the AF_ALG subsystem as an attack surface that requires behavioral monitoring, seccomp restriction for untrusted workloads, and proactive audit coverage.
The four controls that matter most coming out of this series: patch the kernel, deploy auditd rules for AF_ALG socket detection, apply seccomp profiles blocking family 38 for container workloads, and enable live patching for production Linux infrastructure so the next kernel LPE does not require a maintenance window to remediate.
