Linux 'CopyFail' Kernel Privilege Escalation — Root Access on All Major Distributions Since 2017

A privilege escalation vulnerability in the Linux kernel’s copy-on-write (CoW) memory management subsystem — present since a 2017 kernel commit that introduced an edge case in page fault handling — has been publicly weaponised, with a working exploit demonstrating root access on unpatched systems across all major Linux distributions. Dubbed “CopyFail” by the researchers who developed the public exploit, the flaw requires only unprivileged local code execution to escalate to root, making it directly relevant to multi-tenant server environments, containerised workloads, and any Linux host where untrusted code or users can execute processes.

The Vulnerability

CopyFail exploits a race condition in how the Linux kernel handles write faults on copy-on-write memory mappings. When a process writes to a CoW page, the kernel is supposed to make a private copy of that page before allowing the write — preventing one process from modifying memory shared with other processes. The flaw allows a carefully timed sequence of operations to cause the kernel to complete the CoW write without properly completing the copy step, resulting in a private mapping that references kernel-owned memory rather than a true copy.

By exploiting this window, an attacker can overwrite read-only kernel memory — specifically, the kernel’s credential structure for the attacking process — changing its effective UID and GID to 0 (root). The exploit is reliably reproducible on modern hardware and does not require specific kernel configurations or non-default features to be enabled.

The vulnerability exists in kernels from approximately version 4.15 (early 2018) through the unpatched versions of 5.x and 6.x release series. Kernels built before the relevant 2017 CoW refactoring are not affected, but this predates virtually all production Linux deployments.

Affected Distributions

All major Linux distributions running unpatched kernels are affected. Distribution vendors have released or are preparing kernel updates:

Container hosts running the Linux kernel (including Kubernetes nodes, Docker hosts, and cloud VM instances) are affected regardless of whether workloads are containerised — the exploit targets the host kernel, and a containerised attacker who achieves code execution within a container can use CopyFail to escape to root on the host node.

Exploitation Context

CopyFail’s public exploit has a high success rate on standard server configurations. The exploit completes in under 60 seconds on typical server hardware and leaves minimal forensic traces in default kernel logging configurations — the race condition exploitation does not generate standard audit log events unless kernel auditing is explicitly configured to capture process credential changes.

The exploit’s significance for enterprise environments is particularly acute in:

• Multi-tenant hosting environments — shared hosting servers, VM hypervisors, and Kubernetes clusters where tenant workloads run as unprivileged users
• CI/CD build agents — systems where untrusted code (pull request pipelines, external contributor builds) executes in unprivileged contexts
• Database servers with application accounts — MySQL, PostgreSQL, and similar servers where an SQL injection or application compromise provides a limited shell that CopyFail can escalate to root

Recommended Actions

• Apply kernel updates immediately — use your distribution’s package manager to install the patched kernel: apt update && apt upgrade -y (Debian/Ubuntu), dnf update kernel -y (RHEL/CentOS), then reboot to load the patched kernel. Confirm the running kernel version with uname -r.
• Prioritise multi-tenant and container host environments — servers where untrusted code executes are the highest exploitation risk; patch these before single-user or restricted-access systems.
• Review kernel audit configuration — enable auditd rules to monitor for unexpected credential change syscalls (setuid, setresuid, setresgid) as a detection mechanism for exploitation attempts.
• Check container escape exposure — assess whether your container orchestration configuration limits container capabilities appropriately; enable Seccomp profiles and AppArmor/SELinux on container runtimes as defence-in-depth while patches are being applied.
• Verify cloud instance patching — AWS, Azure, and GCP managed services typically provide patched kernel images; confirm your cloud instances are running patched AMIs/images or have received the kernel update via the instance’s package manager.