______ ______ _ __ ______ __
/ ____/___ ____ __ _/ ____/___ _(_) / / ____/_ ______ __________/ /
/ / / __ \/ __ \/ / / / /_ / __ `/ / / / / __/ / / / __ `/ ___/ __ /
/ /___/ /_/ / /_/ / /_/ / __/ / /_/ / / / / /_/ / /_/ / /_/ / / / /_/ /
\____/\____/ .___/\__, /_/ \__,_/_/_/ \____/\__,_/\__,_/_/ \__,_/
/_/ /____/
Fast, auditable Linux exposure assessment and mitigation for CVE-2026-31431 “Copy Fail” while kernels get patched.
CopyFail Guard is a defensive operations tool for Linux sysadmins, DevSecOps engineers, platform teams, and incident responders. It helps reduce exposure to the Linux algif_aead / AF_ALG issue by:
- safely assessing exposure without exploit code
- checking whether
algif_aeadis available, loaded, built-in, or already blocked - installing a persistent
modprobe.dblock and unloading the module when safe - adding an AF_ALG-deny rule to Docker, Podman, and Kubernetes seccomp profiles
- validating AF_ALG reachability without shipping exploit code
Final fix: install your vendor’s patched kernel and reboot.
This tool covers the operational gap between disclosure and full fleet patching.
- No exploit code: checks exposure and AF_ALG reachability without page-cache writes,
splice, setuid changes, privilege escalation, or destructive probes. - Auditable host change: host mitigation writes one managed file,
/etc/modprobe.d/99-copyfail-guard.conf, and rollback removes only that file. - Baseline-preserving seccomp:
seccomp-patchadds an AF_ALG denial to an existing Docker/Podman/Kubernetes seccomp profile instead of replacing your runtime hardening. - Automation ready:
assess --jsonand documented exit codes support fleet scans, SIEM capture, and change-management evidence. - CI covered: shell syntax, seccomp profile generation, JSON output, and smoke tests run across common Linux distro containers.
If you are on a Linux host and need a quick answer:
git clone --depth 1 https://github.com/juliosuas/copyfail-guard.git
cd copyfail-guard
sudo ./bin/copyfail-guard.sh doctor
sudo ./bin/copyfail-guard.sh assessIf the verdict is exposed and algif_aead is modular:
sudo ./bin/copyfail-guard.sh mitigate --yes
sudo ./bin/copyfail-guard.sh verifyFor repeatable installs, pin a release tag:
git clone --branch v0.3.0 --depth 1 https://github.com/juliosuas/copyfail-guard.gitReplace v0.3.0 with the latest tagged release when newer releases are available.
Run the safe exposure check first:
sudo ./bin/copyfail-guard.sh assessHow to read the result:
| Verdict family | What it means | What to do |
|---|---|---|
EXPOSED_* |
algif_aead / AF_ALG appears reachable or loadable |
Mitigate now, then patch and reboot |
PARTIALLY_MITIGATED_* |
A block exists but the loaded module or reboot state still matters | Reboot or unload safely, then verify |
INTERIM_MITIGATED_* |
Local mitigation is active | Keep it, but still patch and reboot |
LOW_OBVIOUS_EXPOSURE_* |
Local checks did not find obvious algif_aead exposure |
Confirm vendor patch status anyway |
If you run untrusted containers, CI jobs, sandboxes, or multi-user workloads, also test whether AF_ALG socket creation is blocked inside that runtime:
python3 tools/afalg-socket-test.pyPERMITTED does not prove successful exploitation, but it proves the relevant userspace crypto API is reachable. For defensive operations, that is enough reason to apply the mitigation while you confirm the patched kernel rollout.
No destructive proof of concept is included. That is a feature, not a gap.
A real Copy Fail exploit proof would need to validate kernel memory/page-cache impact or privilege escalation. Shipping that in a public mitigation repo would make the project less safe and less deployable in production.
CopyFail Guard proves the things operators can safely act on:
- whether the risky component is available, loaded, built-in, or blocked
- whether AF_ALG socket creation is permitted in a target runtime
- whether the host has an interim mitigation in place
- whether the remaining required action is unload, reboot, seccomp, or vendor patching
For final vulnerability status, combine this tool with vendor advisory/package inventory and reboot evidence.
CopyFail Guard is mitigation, not cure. It reduces exposure and verifies interim controls. The durable fix remains vendor patched kernel plus reboot.
The tool is intentionally clone-and-run for incident response: no compiler, kernel headers, exploit code, or third-party package manager is required for the core host workflow. python3 is needed for --json output, seccomp-patch, and the non-exploit AF_ALG socket test.
Clone-and-run:
git clone https://github.com/juliosuas/copyfail-guard.git
cd copyfail-guard
chmod +x bin/copyfail-guard.sh
sudo ./bin/copyfail-guard.sh doctor
sudo ./bin/copyfail-guard.sh assess
sudo ./bin/copyfail-guard.sh mitigate --yes
sudo ./bin/copyfail-guard.sh verifyOptional system install:
git clone https://github.com/juliosuas/copyfail-guard.git
cd copyfail-guard
sudo ./scripts/install.sh
sudo copyfail-guard statusThe installer supports pinning the source and destination for controlled rollouts:
sudo env COPYFAIL_GUARD_REF=v0.3.0 ./scripts/install.shUse the latest tagged release for COPYFAIL_GUARD_REF when newer releases are available.
Container / CI hardening:
./bin/copyfail-guard.sh seccomp-patch docker-default.json copyfail-seccomp.json
docker run --security-opt seccomp=./copyfail-seccomp.json IMAGEValidate that AF_ALG is blocked inside a protected container:
docker run --rm \
--security-opt seccomp=./copyfail-seccomp.json \
-v "$PWD/tools:/tools:ro" \
python:3.12-alpine \
python /tools/afalg-socket-test.pyExpected protected result:
BLOCKED: socket(AF_ALG) denied by policy (...)
See Sample outputs for expected verdicts, JSON shape, and container validation results.
Copy Fail is a Linux kernel local privilege escalation in the algif_aead component of the AF_ALG userspace crypto API. Public advisories describe a page-cache write primitive reachable by unprivileged local users and especially dangerous on shared-kernel systems: Kubernetes nodes, CI/CD runners, multi-tenant hosts, agent sandboxes, and developer boxes.
The correct fix is a vendor kernel update containing the upstream revert/fix and a reboot into the patched kernel. CopyFail Guard is a defensive operations helper for the window before that reboot is complete across the fleet.
| Area | Command | Purpose |
|---|---|---|
| Safe assessment | assess |
Give a non-exploit exposure verdict, next actions, and automation-friendly exit code |
| Dependency check | doctor |
Check required/optional tools and explain runtime limitations |
| Host inspection | status |
Show OS/kernel, module availability, loaded state, built-in warning, modprobe block, and obvious AF_ALG consumers |
| Host mitigation | mitigate |
Write /etc/modprobe.d/99-copyfail-guard.conf and attempt to unload algif_aead |
| Verification | verify |
Fail clearly if the module is loaded, built-in, or not blocked |
| Rollback | rollback |
Remove only CopyFail Guard’s managed modprobe file |
| Containers | seccomp-patch |
Patch an existing seccomp profile to deny socket(AF_ALG, ...) while preserving normal socket use |
| Emergency profile | seccomp-docker |
Generate a targeted AF_ALG-deny profile for emergency use |
| Kubernetes | k8s-example |
Print a Localhost seccomp pod example |
Core host commands:
- Linux
bash- kmod tools:
modinfo,modprobe,lsmod,rmmodwhere available grep,awk,mktemp,install
Optional visibility tools:
lsoforssfor AF_ALG consumer checks
Seccomp profile patching:
python3is required for--json,seccomp-patch, andtools/afalg-socket-test.py
No exploit code, compiler, kernel headers, or third-party packages are required.
CopyFail Guard does not include an exploit proof of concept. That is intentional. See Does this prove vulnerability?.
Instead, assess performs a safe operational check:
- detects whether
algif_aeadappears available, loaded, built-in, or blocked - distinguishes “interim mitigated” from “actually resolved”
- recommends host mitigation, seccomp, or patch/reboot
- returns exit codes for fleet automation
Automation JSON:
sudo ./bin/copyfail-guard.sh assess --json
./bin/copyfail-guard.sh doctor --jsonExit codes:
| Code | Meaning |
|---|---|
0 |
Low obvious exposure from local checks |
1 |
Interim mitigation active, patch/reboot still required |
10 |
Exposed/mitigation available |
11 |
Partially mitigated; reboot or unload needed |
12 |
Built-in module path; patch/reboot required |
20 |
Unknown assessment state |
mitigate writes:
/etc/modprobe.d/99-copyfail-guard.conf
with:
# Managed by CopyFail Guard for CVE-2026-31431
install algif_aead /bin/false
blacklist algif_aead
Then it attempts:
sudo rmmod algif_aeadIf the module is currently in use, rmmod may fail. In that case the persistent block remains installed; stop AF_ALG consumers or reboot after applying the mitigation.
The script refuses to overwrite a symlink at its managed modprobe path and writes the file atomically with safe permissions.
For untrusted workloads, block AF_ALG socket creation with seccomp even while you patch hosts.
Recommended path: patch your existing runtime seccomp baseline instead of replacing it:
./bin/copyfail-guard.sh seccomp-patch docker-default.json copyfail-seccomp.jsonUse with Docker:
docker run --security-opt seccomp=./copyfail-seccomp.json IMAGEUse with Podman:
podman run --security-opt seccomp=./copyfail-seccomp.json IMAGEEmergency-only path if you do not have a baseline profile:
./bin/copyfail-guard.sh seccomp-docker ./copyfail-afalg-seccomp.jsonThe generated emergency profile blocks AF_ALG but otherwise allows syscalls. Treat it as a targeted stopgap, not a replacement for Docker’s normal default seccomp hardening.
For Kubernetes, place the profile under the kubelet seccomp root, commonly:
/var/lib/kubelet/seccomp/profiles/copyfail-seccomp.json
Then reference it with:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/copyfail-seccomp.jsonSee examples/kubernetes-seccomp-pod.yaml.
This project includes a non-exploit AF_ALG reachability test:
python3 tools/afalg-socket-test.pyIt only attempts to create and close an AF_ALG socket. It does not bind crypto operations, call splice, touch setuid binaries, corrupt page cache, or attempt privilege escalation.
Results:
BLOCKEDmeans policy denied AF_ALG for that process.PERMITTEDmeans AF_ALG socket creation is still allowed for that process.UNSUPPORTEDmeans AF_ALG is unavailable in that runtime.
CopyFail Guard needs real-world compatibility reports from Linux hosts, container runtimes, CI runners, and Kubernetes nodes. If you can safely test it, open a Compatibility report issue with sanitized doctor, assess --json, verify, or AF_ALG socket-test output.
Useful reports help answer:
- which distro/kernel/runtime combinations are easy to mitigate
- where
algif_aeadis built in and requires patch/reboot only - which seccomp baselines need runtime-specific notes
- whether docs are clear enough for incident-response use
See Community validation guide.
copyfail-guard assess Safe exposure assessment, no exploit attempt
copyfail-guard status Inspect host exposure indicators
copyfail-guard doctor Check dependencies and runtime readiness
copyfail-guard mitigate Disable algif_aead persistently and unload it
copyfail-guard verify Verify host mitigation is active
copyfail-guard rollback Remove CopyFail Guard's modprobe mitigation
copyfail-guard seccomp-docker [FILE] Generate emergency AF_ALG-deny profile
copyfail-guard seccomp-patch BASE OUT Patch existing seccomp profile safely
copyfail-guard k8s-example Print Kubernetes seccomp example
Flags can be placed before or after the command:
--dry-run Show planned changes without writing files or unloading modules
--yes Non-interactive confirmation
--no-logo Disable ASCII banner
--json Emit JSON for supported commands: assess, doctor
In typical configurations, disabling algif_aead is not expected to affect:
- LUKS / dm-crypt
- SSH
- OpenSSL, GnuTLS, NSS default builds
- kTLS / in-kernel TLS
- IPsec / XFRM
- normal in-kernel crypto consumers
It may affect applications explicitly configured to use the AF_ALG engine or applications that directly create AF_ALG sockets. Check first:
sudo lsof | grep AF_ALG || true
ss -xa | grep -i alg || true- Incident response runbook
- Fleet rollout guide
- Community validation guide
- Sample outputs
- Release checklist
- Seccomp validation notes
- Safe assessment model
- Security policy
- Support policy
- Contributing guide
- Changelog
- Current scope: defensive assessment, host mitigation for modular
algif_aead, seccomp hardening for untrusted workloads, and rollback. - Supported user: operators comfortable with Linux host and container hardening.
- Release style: tagged releases, changelog entries, GitHub Actions smoke tests, and issue templates for reproducible reports.
- Community signal: compatibility reports are the strongest trust signal; field evidence can become docs, tests, and examples.
- Stability promise: avoid exploit behavior, keep host writes narrow, document exit-code semantics, and preserve existing runtime seccomp baselines.
CopyFail Guard does not:
- patch your kernel
- prove whether your exact kernel build is exploitable
- ship exploit code
- protect against already-compromised root users
- replace EDR, fleet inventory, vendor advisories, or reboot planning
Host module mitigation works for modular algif_aead. If algif_aead is built into your kernel, modprobe.d and rmmod cannot disable it; patch/reboot is mandatory and seccomp should be used for untrusted workloads while patching.
Seccomp protects only workloads launched with the profile. Existing running containers or pods must be restarted with the hardened profile.
sudo ./bin/copyfail-guard.sh rollback --yesRollback removes only the file managed by this tool. It does not reload the module. Reboot or manually modprobe algif_aead only if you explicitly need it and have accepted the risk or patched the kernel.
No. Patch and reboot remain the final fix.
No. The project intentionally avoids exploit behavior. tools/afalg-socket-test.py only checks whether AF_ALG socket creation is reachable.
Defense in depth. Container and CI workloads are common places where untrusted code runs on a shared kernel. Seccomp makes the first step of this class of attack unreachable for that workload.
Because default runtime profiles contain many hardening decisions. Replacing them with a minimal emergency profile can accidentally remove protections. seccomp-patch keeps your baseline and adds the AF_ALG denial.
Yes. Start with doctor and assess --json, stage mitigation on a small Linux sample, then roll out host mitigation and seccomp profile changes separately. See Fleet rollout guide.
- NVD: CVE-2026-31431
- CERT-EU advisory: High Vulnerability in the Linux Kernel ("Copy Fail")
- CISA Known Exploited Vulnerabilities entry
- copy.fail public technical advisory
- Linux stable fix:
crypto: algif_aead - Revert to operating out-of-place
Built by Julio César Suástegui Calderón.
Security engineering, Linux systems, and practical defensive automation.
MIT