CVE-2026-64600: Patch Your Homelab XFS Before This LPE

A critical local privilege escalation vulnerability (CVE-2026-64600) affects Linux kernels using XFS. Here's how to check your homelab and patch it.

A server rack in a homelab with a red warning symbol overlaid, representing the CVE-2026-64600 XFS vulnerability.

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.xfs versions, 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 seriesFixed in
5.155.15.212
6.16.1.178
6.66.6.145
6.126.12.96
6.186.18.39
7.17.1.4
mainline7.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.

Frequently Asked Questions

Is my NAS (Synology, QNAP) affected by CVE-2026-64600?
Only if it uses XFS with reflink enabled and runs an unfixed kernel, and an attacker can run code on it as a local user. Many NAS systems use Btrfs or ext4. Check your vendor's advisory rather than guessing.
Can this XFS vulnerability be exploited remotely?
No. It's a local privilege escalation: the attacker needs to run code as an ordinary user first, for example through a compromised web application.
What if I can't patch and reboot right now?
Qualys, which found the bug, says there are no reliable temporary mitigations. Remounting a data volume read-only stops writes to it, but that's rarely practical. Patch and reboot as soon as you can, and because the attack changes files on disk, check critical files afterwards.

Get notified when new articles and designs land:

No spam. Unsubscribe any time.

Sergej Voronko
Sergej Voronko
SAP Basis · Senior Operations Manager · Linux infrastructure engineer
About the author →

[discussion]

Comments are powered by Giscus — backed by GitHub Discussions. Sign in with GitHub to join the conversation.