CVE-2026-64600

What it actually does

This is a local Linux kernel race condition in the XFS filesystem reflink/direct-I/O write path. During copy-on-write handling, the kernel drops and reacquires the XFS inode lock while obtaining a transaction; after that lock cycle, cached data-fork extent mappings can become stale. The vulnerable code refreshes the COW fork mapping but not the corresponding data fork mapping, so later refcount and block-sharing decisions may be made against the wrong physical blocks. A local authenticated user who can trigger the affected XFS direct-I/O/reflink code paths may cause incorrect block mapping decisions, potentially resulting in kernel memory corruption, filesystem metadata/data corruption, denial of service, or privilege-impacting corruption depending on timing and workload.

Why it matters to the business

Successful exploitation can affect the confidentiality, integrity, and availability of systems using affected Red Hat kernel packages with XFS workloads. Operationally, the most likely consequences are system crashes, filesystem corruption, data loss, or service interruption on servers that allow local users, containers, build jobs, database workloads, or other untrusted processes to perform filesystem I/O. Because exploitation requires local privileges and there is no known public exploit or CISA KEV listing, broad internet-scale exploitation risk is lower; however, the high CVSS impact and named threat-actor interest in XFS-related weaknesses mean multi-user Linux hosts, shared compute platforms, and container-dense systems should prioritize remediation.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user on a vulnerable Linux system using XFS. They then create or manipulate files in a way that exercises XFS reflink and copy-on-write behavior, typically involving cloned extents, shared blocks, and direct I/O writes. By racing filesystem activity around the point where the kernel cycles the inode lock, the attacker attempts to change the underlying data fork mapping after it was sampled but before it is reused. If the stale mapping is accepted after the lock is reacquired, XFS can query refcount information for the wrong blocks and make an incorrect shared-versus-private block decision. The final impact depends on timing and memory/filesystem state: the attack may crash the kernel, corrupt file contents or filesystem metadata, or potentially influence kernel behavior in a way that could support local privilege escalation. The reported threat-actor label RefluXFS should be treated as context for heightened monitoring of suspicious local XFS stress/reflink activity, not as proof of widespread exploitation.

How to fix it

Upgrade affected Red Hat kernel packages to the fixed versions or later, then reboot into the updated kernel. Fixed versions include: kernel on Red Hat Enterprise Linux 10 fixed in 6.12.0-211.34.1.el10_2 via RHSA-2026:47981; kernel on Red Hat Enterprise Linux 9 fixed in 5.14.0-570.128.1.el9_6 via RHSA-2026:47981; kernel on Red Hat Enterprise Linux 8 fixed in 4.18.0-372.202.1.el8_6 via RHSA-2026:47981; and kernel-rt on Red Hat Enterprise Linux 8 fixed in 4.18.0-553.144.1.rt7.485.el8_10 via RHSA-2026:47981. Kernel updates are not fully effective until the system is rebooted and running the patched kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, constraining untrusted workloads, avoiding untrusted write access to XFS filesystems, disabling or restricting container workloads that can generate heavy direct-I/O/reflink activity, and increasing monitoring for kernel crashes or XFS corruption messages. Mitigations should be treated as temporary because the vulnerable behavior is in kernel filesystem logic.

How to confirm the fix worked

Confirm remediation by verifying both the installed kernel package version and the currently running kernel after reboot. Use package tooling such as `rpm -q kernel kernel-rt` and runtime checks such as `uname -r`; the running kernel should be at or above the fixed version for the relevant Red Hat release. Confirm systems using XFS with `findmnt -t xfs` or equivalent inventory tooling, and prioritize those hosts for validation. Review bootloader defaults to ensure the system did not boot an older vulnerable kernel. For exposure validation, identify systems running affected Red Hat kernel or kernel-rt package versions below the fixed releases and hosting writable XFS filesystems, especially where local users, containers, CI jobs, or multi-tenant workloads can perform file I/O.

Typical attack path

1. Gain local code execution on a vulnerable Red Hat Enterprise Linux host, container host, or shared compute system.
2. Identify or create a writable XFS filesystem where reflink and copy-on-write behavior can be exercised.
3. Create files with shared extents using reflink-style cloning or copy-on-write workflows.
4. Trigger direct I/O writes and concurrent filesystem operations to force XFS through xfs_reflink_fill_cow_hole or xfs_reflink_fill_delalloc.
5. Race changes to the file extent mapping across the inode lock release/reacquire window.
6. Cause the kernel to reuse a stale data fork mapping and make an incorrect refcount/shared-block decision.
7. Leverage the resulting corruption for denial of service, filesystem/data corruption, or a potential local privilege-impacting condition.

How to detect it

There is no reliable network signature for exploitation because this is a local kernel filesystem race. Detection should focus on host telemetry and forensic artifacts. Review journald, syslog, auditd, kdump, crash dumps, and kernel ring buffers for XFS warnings, kernel oopses, panics, filesystem shutdowns, refcount-btree errors, metadata corruption, or suspicious direct-I/O/reflink activity. Look for repeated use of file cloning/reflink operations followed by direct writes on XFS filesystems by untrusted users or containers. Audit process histories, EDR telemetry, shell histories, and container logs for locally compiled or downloaded filesystem stress tools that exercise XFS reflink, copy-on-write, direct I/O, or race behavior. On systems with kdump enabled, preserve vmcores from crashes for kernel triage. Also review signs of forced `xfs_repair`, remounts, or unexpected read-only filesystem transitions. Because the named actor context includes RefluXFS, SOC teams should correlate unusual XFS stress activity with any related threat-intelligence indicators available internally, while recognizing that no public exploit-specific artifact is currently established from the vulnerability details alone.

• XFS: Metadata corruption detected
• XFS: Internal error
• XFS: Corruption detected
• XFS: log I/O error
• XFS: xfs_do_force_shutdown
• xfs_do_force_shutdown
• xfs_reflink_fill_cow_hole
• xfs_reflink_fill_delalloc
• xfs_find_trim_cow_extent
• xfs_bmap_trim_cow
• kernel BUG at fs/xfs/
• BUG: unable to handle kernel
• general protection fault
• kernel panic
• Oops:
• xfs_repair
• reflink
• FICLONE
• FICLONERANGE
• O_DIRECT
• fsx
• xfstests
• ltp/fsx

What your security team should do

• Prioritize patching and rebooting multi-user Linux systems, container hosts, virtualization hosts, CI/build workers, and servers with writable XFS filesystems.
• Verify the running kernel version after maintenance; do not rely only on package installation status.
• Inventory XFS usage across the Linux fleet and correlate it with affected Red Hat kernel and kernel-rt versions.
• Temporarily restrict untrusted local workloads and write access to XFS filesystems on systems that cannot be patched immediately.
• Monitor kernel, audit, and system logs for XFS corruption, kernel oops/panic events, suspicious reflink-heavy file activity, and repeated direct-I/O stress patterns.
• Investigate unexplained crashes or XFS metadata repair events occurring before patch deployment as possible exploitation or bug-triggering events.
• Track Red Hat advisory RHSA-2026:47981 and downstream kernel updates for all supported releases and real-time kernel variants.
• Treat the low EPSS and absence from CISA KEV as reducing internet-facing urgency, but not local-risk severity; this is still high impact where attackers can run code locally.