Copy Fail and RefluXFS: Two Kernel Privilege Escalation Bugs You Should Patch Now

Copy Fail and RefluXFS: Two Kernel Privilege Escalation Bugs You Should Patch Now

Two separate local privilege escalation vulnerabilities are working their way through distribution security queues this week. Neither requires network access or a misconfigured service, both work from an ordinary unprivileged local account, and one of them is notable for bypassing SELinux even when it is set to Enforcing. If you administer multi-user systems, shared hosting, CI runners, or anything else where untrusted users get a shell, both are worth acting on immediately rather than waiting for your next scheduled maintenance window.

Copy Fail (CVE-2026-31431)

Copy Fail carries a CVSS v3.1 score of 7.8 and affects every major distribution running a kernel released since 2017, which is effectively the entire installed base. The flaw allows a local unprivileged attacker to write arbitrary bytes into the page cache of any file they can read, even files they do not otherwise have write permission to touch.

The page cache is the kernel’s in-memory copy of file contents, used to avoid hitting disk on every read. Under normal conditions, the kernel treats cached pages backing a read-only file as immutable to the calling process. Copy Fail exploits a gap in how that immutability is enforced during certain copy operations, letting an attacker corrupt the cached copy of a file, which the kernel and every other process on the system then treats as the authoritative contents. Chained against a file like a setuid binary or a sudoers configuration, that write primitive becomes a straightforward path to root.

Because the bug lives in a code path that has existed for close to a decade, the patch touches a wide range of kernel versions and distributions are backporting it across supported branches rather than shipping it only in the newest release.

RefluXFS (CVE-2026-64600)

RefluXFS, identified by Qualys’s Threat Research Unit, is a race condition in the XFS filesystem’s copy-on-write path. Copy-on-write is supposed to guarantee that when two processes share a page and one of them writes to it, the kernel transparently duplicates the page first so the write does not corrupt data the other process still expects to see. RefluXFS exploits a narrow timing window in that guarantee: by racing a write against the moment XFS decides whether a page needs duplicating, a local attacker can trick the kernel into modifying a protected file’s on-disk contents directly.

What makes RefluXFS notable is that it works even on systems running SELinux in Enforcing mode, which is normally treated as a strong mitigation against exactly this class of local privilege escalation. The race lives below the layer SELinux mediates, so policy enforcement does not see anything to block.

Who’s affected

Any system using the XFS filesystem is a candidate for RefluXFS, which makes it particularly relevant to RHEL, Fedora, and other distributions where XFS is the default or a common choice for server installs. Copy Fail is filesystem-agnostic and affects the page cache mechanism directly, so it is not limited to any one filesystem or distribution.

Systems where the practical risk is highest are the ones that hand out local shell access to people you do not fully trust: shared university or lab servers, CI/CD runners that execute untrusted job code, multi-tenant hosting boxes, and container hosts where a compromised container can reach the host kernel.

What to do

Check your distribution’s security advisories for CVE-2026-31431 and CVE-2026-64600 and apply the available kernel update as soon as it is out for your branch. Both are kernel-level fixes, so a reboot is required before the running system is actually protected, installing the package alone is not enough.

# Debian/Ubuntu
apt list --upgradable | grep linux-image

# Fedora/RHEL
dnf check-update kernel

# Arch
pacman -Qi linux | grep Version

# openSUSE
zypper list-patches --category security

If you are running XFS on a system where RefluXFS is a realistic threat model, and cannot patch immediately, reducing the number of local users with unprivileged shell access is the only meaningful stopgap until the update lands.

Background reading

Explainers for the concepts behind this story.