Issue
RefluXFS (CVE-2026-64600) is a local privilege escalation vulnerability in the Linux kernel's XFS filesystem, publicly disclosed on 07/22/26 together with a working proof-of-concept exploit. A race condition in the copy-on-write (reflink) direct-I/O path lets an unprivileged local user overwrite the on-disk contents of any file they can read, for example /etc/passwd or a setuid-root binary such as /usr/bin/su, and thereby gain full root.
The change is written directly at the block layer, so it persists across reboot, produces no kernel log output, and does not touch the target file's inode, which means a modified setuid-root binary keeps its setuid bit. Customers are asking whether CloudLinux OS kernels are affected and whether a KernelCare patch is available.
Environment
- CloudLinux OS (CL8, CL9, CL10)
- KernelCare
- Any XFS filesystem created with
reflink=1(themkfs.xfsdefault since 2019, and the CloudLinux default)
Solution
1. Confirm whether the filesystem is exposed. Reflink is a superblock feature fixed at filesystem creation time. Check your root filesystem, and repeat for any other mounted XFS:
xfs_info / | grep reflink=
If the output contains reflink=1, that filesystem is exposed. If it shows reflink=0, or if xfs_info fails because the mount point is not XFS, that filesystem is not exposed through this path.
2. Fixes. The patched CL8 kernel is available in our rollout repositories. Target version:
- CL8: kernel-4.18.0-553.144.1.lve.el8 or newer
To update, please run:
dnf update 'kernel*' --enablerepo=cloudlinux-rollout*
Note: In case the required package is absent, ensure that the latest сloudlinux-release-8.10-15 installed and rename .repo.rpmnew files into .repo in /etc/yum.repos.d/
rpm -Uhv https://repo.cloudlinux.com/cloudlinux/8/cloudlinux-release-latest-8.rpm
The patched CL9/CL10 are available in the stable repository. Target versions:
- CL9: kernel-5.14.0-687.26.1.el9_8 or newer
- CL10: kernel-6.12.0-211.34.1.el10_2 or newer
3. There is no supported runtime workaround. Reflink cannot be turned off on a live filesystem: it is a superblock feature set at mkfs time, with no mount option or sysctl to disable it afterwards. An updated kernel or a KernelCare live patch is therefore what will close this issue.
4. Watch for the announcement. Further updates regarding the security patch will be published on the CloudLinux blog.
Cause
When an O_DIRECT write targets a reflinked file, XFS decides in xfs_direct_write_iomap_begin() whether the target block is shared and needs copy-on-write. Allocating the copy-on-write transaction can require waiting for log space, so xfs_reflink_allocate_cow() drops the inode ILOCK, allocates the transaction, and re-acquires the lock. On re-acquire it re-checks the block's reference count, but at the physical block number captured before the lock was dropped, and it never re-reads the data fork.
A second O_DIRECT writer running concurrently (block-aligned direct writes hold only the shared IOLOCK) can complete a full copy-on-write cycle inside that window: allocate a new block, remap the file to it, and drop the original block's reference count. The first writer then sees the reference count as 1, concludes the block is private, and writes in place, into the physical block that now solely backs the reflink source, which is the target file. The bug was introduced in Linux 4.11 (2017) and fixed upstream on 07/16/26 (commit 2f4acd0, "xfs: resample the data fork mapping after cycling ILOCK").
Comments
0 comments
Please sign in to leave a comment.