> For the complete documentation index, see [llms.txt](https://0xsec.gitbook.io/0xsec/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xsec.gitbook.io/0xsec/blogs/cve-2026-64600-refluxfs-linux-kernel-flaw-leads-to-root-privilege-escalation.md).
# CVE-2026-64600: RefluXFS Linux Kernel Flaw Leads to Root Privilege Escalation
### Copy On Write in XFS
[**Copy-on-write** (**COW**)](https://stackoverflow.com/questions/628938/what-is-copy-on-write), also called **shadowing**, is a resource-management technique used to manage shared data efficiently. Instead of copying data right away when multiple programs use it, the same data is shared between programs until one tries to modify it. If no changes are made, no private copy is created, saving resources. A copy is only made when needed, ensuring each program has its own version when modifications occur.
XFS preserves "the usual" file semantics even when two files share the same physical blocks means write to one file must not alter the block in other file. It is achieved by this mechanism, it can understood as when we want to write to a shared block, it will allocate a new block and write the data to that new block, if the write succeeds it will map the new block into file.
To understand it more better lets a example, in a traditional file system when you copy a file of let’s say 2GB, it reads the data and writes 2GB identical data somewhere else So now you 4GB storage is used. But in filesystems that use CoW mechanism, when the same 2GB file is copied, the OS creates a new file name but under the hood it just points to exact same physical block of original file. When changes are to be made on specific chunk of this newly created file, the filesystem allocates a new block and writes the data to it and updates the pointer for that specific chunk to this new allocated block and original file remains untouched.
XFS achieve this with a help of [reflink](https://github.com/torvalds/linux/blob/master/fs/xfs/xfs_reflink.c), and it uses **ReferenceCount** to keep track that the block is shared or private. If XFS sees this reference count set to >1 then that block is shared and it allocates new block and write data to it and if it is set to 1 then the block is private.
### What Caused this Vulnerability
This vulnerability was a race condition on XFS CoW, it is triggered when two concurrent `O_DIRECT` writes operation was done on a same reflink file. So as I explained earlier that XFS uses CoW mechanism to handle writes on a shared block by allocating a new block, remaping the pointers, and decrements original block’s **reference count.** The issue arise where it drops the lock on `INODE` while waiting for completion of transaction log space.
Comment from developer says that during this window of log space transaction, another `O_DIRECT` writer with `IOLOCK_SHARED` can complete a full CoW cycle, which will remaps this block and decrement the **ReferenceCount** on original shared block. When the first writer re-acquires the lock, it will now re-checks the reference count on original physical block address of file. Seeing count of one, it incorrectly assumes the block is private and proceeds to write directly to the original file’s physical block. It lacks revalidation, the write persists to disk, overwriting the original file. They have applied the patch, now it re-checks for sequence before dropping lock and after acquiring it.
### Exploitation Steps
The exploitation requires three conditions:
* The system runs Linux 4.11 or later without the RefluXFS fix.
* The XFS filesystem was created with `reflink=1`.
* The readable target and an attacker-writable directory are on the same XFS filesystem.
The exploit opens /etc/passwd read-only, then per attempt:
1. Reflink-clones `/etc/passwd` into a scratch file under `/var/tmp` (open `O_RDWR|O_CREAT|O_TRUNC`, then ioctl `FICLONE`on the same fd). The first block of both files now points at the same physical block X; `refcount(X) = 2`.
2. Releases 32 threads, barrier-synchronized so they all start at once, each opening the clone `O_RDWR|O_DIRECT` and issuing one `4KB` write at offset 0. Every thread enters `fill_cow_hole()`with `imap = X` and drops the `ILOCK` to wait for a transaction.
3. Whichever thread gets its transaction first, completes the full CoW cycle -- allocate Y, write, `end_cow`remaps clone from X to Y, `refcount(X)` drops from 2 to 1.
4. Whichever thread gets its transaction second re-checks "is X still shared?", sees `refcount(X) = 1`, and its write is submitted in place -- to block X, which is now solely /etc/passwd's block.
5. If no thread landed in the window this round, go back to step 1 (the `O_TRUNC` there frees the previous round's CoW block). Eight background threads doing ftruncate/fdatasync loops on scratch files widen the window by making transaction allocation stall for log space.
### PoC
PoC -
{% embed url="" %}
### Refrences
\
\
\
\
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://0xsec.gitbook.io/0xsec/blogs/cve-2026-64600-refluxfs-linux-kernel-flaw-leads-to-root-privilege-escalation.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
