CVE-2026-31431 - Copy Fail - Je s'appelle ROOT !#

📌 Repository Purpose

This repository documents the CVE-2026-31431 vulnerability, nicknamed Copy Fail, and provides a defensive remediation procedure for potentially exposed Linux systems.

⚠️ This repository is strictly focused on defense, authorized auditing, hardening, and remediation.
It does not provide an exploitation procedure and must not be used to compromise third-party systems.

---

1. Executive Summary

CVE-2026-31431 / Copy Fail is a local privilege escalation vulnerability in the Linux kernel.

It affects the kernel's cryptographic subsystem, more specifically the AF_ALG user interface and the algif_aead module. The flaw is related to an optimization introduced in 2017 in the Linux kernel's AEAD path. Under certain conditions, an unprivileged local user can trigger a controlled write into the page cache of a readable file, notably a setuid binary, which can lead to privilege escalation to root.

The vulnerability is rated High with a CVSS v3.1 score of 7.8.

---

2. CVE Information

Element	Detail
CVE	CVE-2026-31431
Public name	Copy Fail
Type	Local Privilege Escalation, LPE
Component	Linux kernel crypto subsystem
Affected module	algif_aead
Interface	AF_ALG
Mechanism involved	AEAD, authencesn, splice(), page cache
CVSS v3.1 score	7.8 High
Privileges required	Unprivileged local account
User interaction	None
Impact	High confidentiality, integrity, and availability

---

3. Affected Systems

Public sources indicate that Linux distributions shipping a kernel derived from a vulnerable branch since the 2017 optimization may be exposed.

Examples of platforms mentioned in public publications:

Distribution	Example of publicly tested kernel version
Ubuntu 24.04 LTS	6.17.0-1007-aws
Amazon Linux 2023	6.18.8-9.213.amzn2023
RHEL 10.1	6.12.0-124.45.1.el10_1
SUSE 16	6.12.0-160000.9-default
Debian	Depending on kernel version and security status
AlmaLinux / Rocky Linux / Oracle Linux	Depending on kernel version and vendor backports

The exact status depends on the kernel version, vendor, security backports, and already applied patches.

---

4. Why This Flaw Is Critical

This vulnerability is particularly dangerous in environments where untrusted users or workloads have access to a local shell or a shared execution environment.

Environments to prioritize:

• multi-user servers;
• SSH servers exposed to multiple accounts;
• training or lab platforms;
• CI/CD runners;
• build servers;
• Kubernetes clusters;
• container hosts;
• shared hosting platforms;
• multi-tenant cloud environments.

Main risk:

• local escalation to root;
• host compromise;
• partial bypass of disk integrity controls because the modification can reside in memory via the page cache;
• potential impact on containers sharing the same host kernel.

---

5. Quick Verification

5.1 Identify the kernel version

uname -a
uname -r

5.2 Check whether the algif_aead module is loaded

lsmod | grep algif_aead || true

5.3 Check whether AF_ALG sockets are in use

sudo lsof -nP | grep AF_ALG || true

5.4 Identify installed kernel packages

Debian / Ubuntu

dpkg -l | grep -E '^ii\\s+linux-image|^ii\\s+linux-modules'

RHEL / Rocky / AlmaLinux / Fedora

rpm -qa | grep -E '^kernel|^kernel-core'

SUSE

rpm -qa | grep -E '^kernel'

6. Recommended Remediation

Priority option: apply the vendor kernel patch The proper remediation is to install a patched kernel provided by the distribution, then reboot onto that kernel.

Debian / Ubuntu

sudo apt update
sudo apt full-upgrade -y
sudo reboot

RHEL / Rocky / AlmaLinux / Oracle Linux

sudo dnf update -y kernel kernel-core kernel-modules
sudo reboot

SUSE

sudo zypper refresh
sudo zypper patch
sudo reboot
# After reboot:
uname -r

• Then check the status in the distribution's security tracker.

7. Temporary Mitigation

If no patched kernel is yet available or if an immediate reboot is impossible, apply a temporary mitigation.

7.1 Disable loading of algif_aead

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf

7.2 Unload the module if already loaded

sudo modprobe -r algif_aead 2>/dev/null || true
sudo rmmod algif_aead 2>/dev/null || true

7.3 Update the initramfs if necessary

Debian / Ubuntu

sudo update-initramfs -u

RHEL / Rocky / AlmaLinux / Oracle Linux

sudo dracut -f

SUSE

sudo mkinitrd

7.4 Reboot

sudo reboot

7.5 Verify that the module can no longer be loaded

sudo modprobe algif_aead
echo $?

• Expected result: loading must fail.

8. Special Case: Module Compiled Directly Into the Kernel

On some kernels, the module may be compiled directly into the kernel and cannot be loaded/unloaded as a module.

• Indicative check:

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

• Possible results:

CONFIG_CRYPTO_USER_API_AEAD=m

The component is a module. The mitigation via /etc/modprobe.d/ is applicable.

CONFIG_CRYPTO_USER_API_AEAD=y

The component is built into the kernel. The modprobe.d mitigation is not sufficient.

In this case, preferably use:

• a patched kernel;
• a vendor livepatch if available;
• a boot option documented by your vendor.

Some sources mention the following kernel option as a possible workaround:

initcall_blacklist=algif_aead_init

Must be tested outside production before general deployment. This option may vary depending on the kernel, distribution, and boot configuration.

9. Hardening Containerized Environments

For Docker, Podman, Kubernetes, and CI/CD, the ability for untrusted workloads to open AF_ALG sockets must be reduced.

Recommended measures:

• Apply the kernel patch on host nodes;
• Block or restrict AF_ALG via seccomp when possible;
• Avoid privileged workloads;
• Forbid privileged: true containers unless absolutely necessary;
• Enable AppArmor, SELinux, or equivalent;
• Isolate CI/CD runners executing untrusted code;
• Prefer dedicated nodes for sensitive workloads.

10. Detection and Monitoring

10.1 Search for AF_ALG usage

sudo lsof -nP | grep AF_ALG || true

10.2 Search for the loaded module

lsmod | grep algif_aead || true

10.3 Monitor critical setuid binaries

find / -perm -4000 -type f 2>/dev/null

10.4 Monitor suspicious access to /usr/bin/su

sudo ausearch -f /usr/bin/su 2>/dev/null || true

10.5 Example auditd rule

sudo auditctl -w /usr/bin/su -p x -k su_exec_monitoring

• Then consult:

sudo ausearch -k su_exec_monitoring

11. Incident Action Plan

If exploitation is suspected:

• Isolate the machine from the network;
• Preserve logs;
• Reboot to purge the page cache;
• Verify system integrity;
• Review local accounts;
• Look for recently added SSH keys;
• Check cron and systemd tasks;
• Rotate passwords and secrets;
• Apply the patched kernel;
• Reboot and validate the active version;
• Reintegrate the machine only after verification.

Useful commands:

last -a
lastlog
getent passwd
sudo find /etc/cron* -type f -ls 2>/dev/null
sudo find /root /home -name authorized_keys -type f -ls 2>/dev/null
sudo journalctl --since "48 hours ago"

12. Remediation Checklist