Severity: High (Red Hat: Important)

Status: Patches available — immediate action required

1. Summary
2. Impacted versions
3. Recommendations
4. Detection & verification
5. References
6. Support

A flaw in the Linux kernel lets any user with an ordinary, non-privileged login take complete control of the system as root. No special permissions or unusual configuration are needed. The flaw is in XFS, the default filesystem on Red Hat Enterprise Linux and the distributions derived from it, and allows an attacker to rewrite protected system files directly on disk. The changes survive a reboot, and the file’s ownership, permissions, and timestamps are left untouched — so the file looks normal to anything that inspects it.

Two things make this worse than a typical privilege escalation. The usual protective layers do not help: SELinux in Enforcing mode, container isolation, and kernel memory protections all operate above the level where the flaw occurs. And exploitation produces no kernel log entries, leaving little to alert on or find afterwards. The bug has existed since 2017; Qualys estimate over 16.4 million systems are affected and rates it an emergency priority. There is no workaround — patching the kernel and rebooting is the only fix.

Priority should go to any system where users not already trusted with root can log in or run code: shared and multi-tenant hosts, research computing login nodes, build and CI runners, jump hosts, and container hosts running untrusted workloads.

XFS lets two files share the same physical blocks on disk until one is written to, at which point the kernel makes a private copy. The bug is a timing window in that copy step: the kernel briefly releases its lock on the file, and if a second write completes during that window, the first write re-checks the block using a stale address, concludes the block is private, and writes to it directly. Because direct I/O bypasses the page cache, the data lands on disk in the original file. The result is that an unprivileged user can overwrite the contents of any file they can read on a reflink-enabled XFS volume — Qualys demonstrated this against /etc/passwd and SUID-root binaries.

All three conditions must be true: (1) Linux kernel 4.11 or later without the fix; (2) an XFS filesystem with reflink=1; (3) the volume holds both a root-owned target (config file or SUID-root binary) and a directory the user can write to. Default installations of the distributions below meet all three out of the box.

• Affected by default: RHEL 8/9/10, CentOS Stream 8/9/10, Oracle Linux 8/9/10, Rocky Linux and AlmaLinux 8/9/10, CloudLinux 8/9/10, Amazon Linux 2023 and Amazon Linux 2 AMIs from Dec 2022 onward, Fedora Server 31+. Other RHEL-derived distributions should be assumed vulnerable until confirmed otherwise.
• Not affected by default: Debian, Ubuntu, SUSE — these do not use XFS as the default root filesystem. In scope only where an administrator selected XFS with reflink at install time.

Red Hat issued Important-rated errata from July 14, eight days ahead of disclosure — systems patched on the normal July cycle may already be covered.

Key advisories: RHSA-2026:39179 and 39180 (RHEL 8), RHSA-2026:39494 (RHEL 10), with further RHSAs for additional, extended-support, and SAP streams through July 17.

Equivalents: ELSA-2026-39494 (Oracle), ALSA/RLSA-2026:39179, 39180, 39494 (AlmaLinux, Rocky), FEDORA-2026-085c9e92a4.

Errata coverage is stream-specific — confirm an advisory exists for the exact release each host runs.

• Patch and reboot: The running kernel is what matters — an installed but unbooted kernel gives no protection. Verify with uname -r post-reboot rather than trusting the package database.
• Prioritize by local user population: Rank hosts by how many users can log in and how trusted they are. Shared research nodes, student-accessible hosts, CI runners, and multi-tenant systems first; single-admin servers can follow in the normal cycle.

Confirm exposure (read-only, safe at scale):

for m in $(findmnt -nt xfs -o TARGET); do echo "$m $(xfs_info $m 2>/dev/null | grep -o 'reflink=[01]')"; done

Detecting exploitation is genuinely difficult and should not be overstated. There is no kernel log output, and the overwrite alters file contents at the block layer without touching the inode — ownership, permissions, timestamps, and the SUID bit are all preserved. File integrity monitoring keyed on metadata alone will report clean on a compromised file. Only hash- or content-based checking will catch it.

• [Qualys TRU advisory] – RefluXFS: A Linux Kernel Local Privilege Escalation to Root in XFS (CVE-2026-64600)
• [oss-security disclosure] – RefluXFS: Local Privilege Escalation via XFS reflink direct-I/O race (CVE-2026-64600)
• [Red Hat customer portal] – CVE-2026-64600 (RefluXFS) vulnerability in Red Hat Enterprise Linux 8 and later
• [NVD entry] – CVE-2026-64600 detail

As always, please let us know if you have any questions or concerns or see unusual activity on your systems that you believe might be associated with this or any other vulnerability. Please send these communications to security.response@utoronto.ca.