CVE-2026-64600, nicknamed RefluXFS, is a Linux kernel local privilege escalation in the XFS filesystem, found by the Qualys Threat Research Unit and published in July 2026. An ordinary local user can overwrite the on-disk contents of files they can only read, such as /etc/passwd or a setuid-root binary, and become root. According to Qualys this works even with SELinux enforcing.
What the bug is
The kernel record’s title is “xfs: resample the data fork mapping after cycling ILOCK.” In XFS’s copy-on-write path for reflinked files, the kernel briefly drops the inode lock while waiting for space in the transaction log. When it takes the lock back, it can continue with a stale mapping of where the file’s data lives. Public write-ups describe the exploit as two concurrent O_DIRECT writes to the same reflinked file, which win that race and write over blocks belonging to another file.
Two consequences matter:
- It needs XFS with reflink enabled. Reflink is the default for filesystems made by recent
mkfs.xfsversions, so most modern XFS volumes have it. - The damage is on disk: unlike page-cache bugs, the change survives a reboot and leaves very little trace.
Am I affected?
Check for XFS and whether reflink is on:
findmnt -t xfs # XFS filesystems currently mounted
xfs_info /path/to/mountpoint | grep -o 'reflink=[01]'
uname -r
reflink=1 plus an unfixed kernel means exposed. XFS is the default root filesystem on RHEL, Rocky and AlmaLinux. On Debian, Ubuntu and Proxmox VE installs it only appears if you chose it, since the installers default to ext4, LVM or ZFS.
Fixed kernels per the CVE record:
| Kernel series | Fixed in |
|---|---|
| 5.15 | 5.15.212 |
| 6.1 | 6.1.178 |
| 6.6 | 6.6.145 |
| 6.12 | 6.12.96 |
| 6.18 | 6.18.39 |
| 7.1 | 7.1.4 |
| mainline | 7.2 |
Affected since 4.11. Distribution kernels use their own version numbers, so check your distro’s advisory for CVE-2026-64600.
Patch
# Debian / Ubuntu / Proxmox
sudo apt update && sudo apt full-upgrade
# RHEL / Rocky / Alma / Fedora
sudo dnf upgrade --refresh
# Arch
sudo pacman -Syu
Use full-upgrade on Debian-based systems so new kernel packages get installed. Then reboot and confirm with uname -r. A kernel update does nothing until you boot into it.
Mitigation if you can’t patch yet
Qualys states there are no reliable temporary mitigations. The only hard stop is preventing writes: an XFS data volume that untrusted users can reach can be remounted read-only (sudo mount -o remount,ro /mountpoint), which is rarely practical and impossible for an XFS root filesystem. Otherwise, reduce who can run code on the host, and patch.
After patching: check for tampering
Because the overwrite lands on disk, patching doesn’t undo an attack that already happened. On machines where untrusted users or exposed services could run code, check the files an attacker would target:
# RPM-based: verify installed files against the package database
sudo rpm -Va | grep -E '^..5' | grep -E ' /(etc|usr/bin|usr/sbin)/'
# Debian-based (debsums package)
sudo debsums -c
Also look at /etc/passwd, /etc/shadow and /etc/sudoers for entries you don’t recognise.
What’s Next
Once your systems are patched, it’s a good time to review your overall security posture. A single vulnerability is rarely the whole story.
- Tighten up your server’s defenses with our Ultimate Proxmox Hardening Guide.
- Prevent future patching fire drills by configuring Unattended Upgrades for Your Linux Servers.
- Apply the same security principles to your cloud infrastructure by Securing EC2 Instances From the Ground Up.
[discussion]
Comments are powered by Giscus — backed by GitHub Discussions. Sign in with GitHub to join the conversation.