modules: add refluxfs (CVE-2026-64600, "RefluXFS" XFS reflink CoW ILOCK race)

Adds the corpus's first XFS module and its first data-oriented kernel bug —
every other kernel entry corrupts memory; this one corrupts file contents.

xfs_direct_write_iomap_begin() reads the data-fork extent map under ILOCK,
then xfs_reflink_fill_cow_hole() drops ILOCK to wait for transaction log
space. On reacquiring it, the code re-queries the refcount btree at the
ORIGINAL imap->br_startblock and never re-reads the data fork. A second
O_DIRECT writer holding only IOLOCK completes a whole CoW cycle in that
window, so the first writer's stale mapping sees refcount 1, treats a
still-shared block as private, and writes to it in place — landing its data
on the reflink source file's on-disk blocks.

The primitive is an arbitrary overwrite of the on-disk contents of any
readable file, which has three consequences that drive the design:
  - No offsets, no ROP, no KASLR/SMEP/SMAP; SELinux, containers and seccomp
    are all irrelevant.
  - The victim's inode is never written, so mtime/ctime/size never change
    and nothing is logged — FIM and `-w /etc/passwd -p wa` cannot see it.
  - The change persists across reboots.

Introduced 4.11 (3c68d44a2b49); fixed 2f4acd0fcd86 (mainline 7.2-rc4,
merged 2026-07-16), stable backports 7.1.4 / 6.18.39 / 6.12.96. Exposure is
distro-shaped: RHEL/CentOS/Rocky/Alma/Oracle/CloudLinux 8-10, Fedora Server
>= 31 and Amazon Linux 2023 ship XFS+reflink by default.

detect() is not a pure version gate — reachability here is safely
observable, so it pairs the backport table with a real storage precondition
(writable XFS via statfs XFS_SUPER_MAGIC, deliberately not via a successful
FICLONE since btrfs implements that too and is unaffected). --active
confirms reflink via FICLONE; SKELETONKEY_XFS_ASSUME_REFLINK=1/0 overrides.
On rpm-family hosts it warns that vendors backport without bumping the
upstream version, so the verdict speaks only to the upstream base.

exploit() forks a child that works only in a private mkdtemp scratch dir on
two files it owns: it establishes a shared extent (FICLONE, corroborated by
FIEMAP_EXTENT_SHARED) plus an O_DIRECT gate, then races a hard-bounded
8 writers / 2 helpers / 16 rounds / 2s and stops, reading the donor back
with O_DIRECT. Deliberately under-driven, and it never clones or targets a
file it does not own — the /etc/passwd overwrite -> su -> root step is
documented but NOT bundled. Always returns EXPLOIT_FAIL.

Safety rank 55, far above bad_epoll (12) and ghostlock (11): a won race
corrupts 4 KiB of our own scratch file and cannot touch kernel memory, so
there is no oops/KASAN/panic path.

Detection inverts the usual advice. auditd/sigma anchor on ioctl request
0x40049409 (FICLONE, matched exactly) and openat O_DIRECT; falco adds the
cross-uid reflink condition; and the yara rule is genuinely the right tool
here, matching the on-disk artifact because FIM is structurally blind.

VM-VERIFIED 2026-07-23 — the corpus's first rpm-family verification, taking
the empirical count to 29 of 41 CVEs. Rocky Linux 9.8 /
5.14.0-687.10.1.el9_8.0.1.x86_64 under qemu/KVM, stock GenericCloud layout
with no provisioner changes (root is XFS with reflink=1 out of the box).
detect() -> VULNERABLE, --active FICLONE witness confirmed reflink, phase A
observed FIEMAP_EXTENT_SHARED on a real shared extent, scratch self-cleaned,
clean build on el9 gcc. The underlying bug was separately confirmed winnable
on that kernel via tools/verify-vm/refluxfs_verify.c at the public PoC's
parameters (32 writers / 8 helpers, 60s): 4/4 runs won, first divergence
after 69/114/170/494 rounds. The shipped under-driven trigger did NOT win in
its 2s budget on that same vulnerable kernel — intended behaviour, and
exactly why a non-win must never be read as "patched".

14 new detect() unit rows (148 tests total, 0 failures). Bumps to v0.9.14.

Credit: Qualys Threat Research Unit (blog by Saeed Abbasi; the technical
advisory credits model-assisted kernel analysis performed with Anthropic),
and the upstream XFS maintainers who fixed it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y

docs/CVE_METADATA.json

@@ -358,5 +358,14 @@
     "attack_subtechnique": null,
     "in_kev": false,
     "kev_date_added": ""
+  },
+  {
+    "cve": "CVE-2026-64600",
+    "module_dir": "refluxfs_cve_2026_64600",
+    "cwe": null,
+    "attack_technique": "T1068",
+    "attack_subtechnique": null,
+    "in_kev": false,
+    "kev_date_added": ""
   }
 ]

docs/KEV_CROSSREF.md

@@ -4,7 +4,7 @@ Which SKELETONKEY modules cover CVEs that CISA has observed exploited
 in the wild per the Known Exploited Vulnerabilities catalog.
 Refreshed via `tools/refresh-cve-metadata.py`.
 
-**13 of 40 modules cover KEV-listed CVEs.**
+**13 of 41 modules cover KEV-listed CVEs.**
 
 ## In KEV (prioritize patching)
 
@@ -59,3 +59,4 @@ and are technically reachable. "Not in KEV" is not the same as
 | CVE-2026-46243 | CWE-20 | `cifswitch_cve_2026_46243` |
 | CVE-2026-46300 | CWE-787 | `fragnesia_cve_2026_46300` |
 | CVE-2026-46333 | CWE-269 | `ptrace_pidfd_cve_2026_46333` |
+| CVE-2026-64600 | ? | `refluxfs_cve_2026_64600` |

docs/RELEASE_NOTES.md

@@ -1,3 +1,129 @@
+## SKELETONKEY v0.9.14 — new LPE module: refluxfs (CVE-2026-64600)
+
+Adds **`refluxfs` — CVE-2026-64600 "RefluXFS"** (Qualys Threat Research Unit),
+taking the corpus to **46 modules / 41 CVEs** and opening a brand-new subsystem:
+**XFS reflink copy-on-write** (`fs/xfs/xfs_iomap.c`, `fs/xfs/xfs_reflink.c`). It
+is also the corpus's first **data-oriented** kernel bug — every other kernel
+entry in the set corrupts memory; this one corrupts file contents.
+
+`xfs_direct_write_iomap_begin()` reads the data-fork extent map under `ILOCK`,
+then `xfs_reflink_fill_cow_hole()` **drops `ILOCK`** to allocate a transaction
+(i.e. to wait for log space). On re-acquiring it, the code re-queries the
+refcount btree at the **original** physical block number (`imap->br_startblock`)
+and **never re-reads the data fork**. A second `O_DIRECT` writer holding only the
+coarser `IOLOCK` can complete an entire CoW cycle inside that window — allocate
+block Y, write it, remap via `xfs_reflink_end_cow()` — leaving the first writer's
+mapping pointing at a block now owned solely by the reflink **source**. The stale
+lookup returns refcount `1`, the writer concludes the block is private, and
+writes to it in place, landing attacker data on the source file's on-disk blocks.
+
+Three properties make this unlike anything else in the corpus:
+
+- **No offsets, no ROP, no KASLR/SMEP/SMAP.** The primitive is an arbitrary
+  overwrite of the *on-disk contents of any readable file*, so there is nothing
+  to port per kernel build and no `--full-chain` offset entry to fill. Qualys is
+  explicit that SELinux enforcing, container boundaries and seccomp are equally
+  irrelevant: *"This isn't a vulnerability you can harden around, isolate, or
+  live-patch."*
+- **File-integrity monitoring cannot see it.** The data is applied to the shared
+  physical block *beneath* the victim inode. No `write(2)` ever targets it, so
+  `mtime`/`ctime`/size are unchanged and nothing is logged — `-w /etc/passwd -p
+  wa`, AIDE and Tripwire all stay silent. The change persists across reboots.
+- **The exposure is distro-shaped, not kernel-shaped.** What matters is whether
+  XFS+reflink is the installer default: **RHEL/CentOS Stream/Rocky/AlmaLinux/
+  Oracle/CloudLinux 8-10, Fedora Server ≥ 31 and Amazon Linux 2023** are
+  exploitable out of the box; Debian, Ubuntu, Fedora Workstation, SLES, openSUSE
+  and Arch default to ext4/btrfs and are not reachable. RHEL/CentOS 7 (3.10) was
+  never affected.
+
+Introduced **4.11** (2017-02, `3c68d44a2b49`) — a nine-year window. Fixed by
+`2f4acd0fcd86` ("xfs: resample the data fork mapping after cycling ILOCK"),
+merged **2026-07-16** for **7.2-rc4**; stable backports **7.1.4** / **6.18.39** /
+**6.12.96**. The 6.6 / 6.1 / 5.15 / 5.14 / 5.10 / 4.19 / 4.18 lines have no
+upstream stable fix in the CNA record at time of writing. CWE-362 → CWE-367; NVD
+published neither a CWE nor a CVSS vector at time of writing; not in CISA KEV.
+
+🟡 **Trigger (reconstructed) — deliberately under-driven, and VM-VERIFIED.**
+Unlike the corpus's other race
+modules, `detect()` is **not** a pure version gate: this bug's reachability is
+safely observable, so it pairs the three-branch version table with a **real
+storage precondition** — a writable directory on a mounted XFS filesystem,
+identified by `statfs(2)` `f_type == XFS_SUPER_MAGIC` and deliberately **not** by
+a successful `FICLONE`, since btrfs implements `FICLONE` too and is unaffected.
+No such directory → `PRECOND_FAIL`, the correct verdict on a stock Debian/Ubuntu
+host. Under `--active` it confirms `reflink=1` empirically; override with
+`SKELETONKEY_XFS_ASSUME_REFLINK=1/0`. On rpm-family hosts it warns explicitly
+that RHEL/Oracle/Rocky/Alma backport **without bumping the upstream version** (a
+patched el8 kernel still reports `4.18.0-*`), so the verdict reflects the
+upstream base version only — check the RHSA/ELSA/ALSA/RLSA erratum.
+
+`exploit()` forks an isolated child that creates a private `mkdtemp` scratch
+directory and works **only on two files it owns**: **(A)** it writes a donor,
+`FICLONE`-clones it, and confirms the shared extent via **`FIEMAP_EXTENT_SHARED`**
+plus an `O_DIRECT` gate — a read-only, deterministic observation that the exact
+refcount state the bug misjudges exists here; then **(B)** it races **8**
+concurrent `O_DIRECT` 4 KiB writes against the clone with **2**
+`ftruncate`/`fdatasync` helpers cycling the `ILOCK`, for at most **16 rounds /
+2 s**, and stops — reading the donor back with `O_DIRECT`, because a buffered read
+would be served from the page cache the corruption bypasses and would hide a win.
+It is deliberately under-driven against the public PoC's 32 writers and 8
+helpers, and it **never clones or targets a file it does not own**: the step that
+yields root — reflink-cloning `/etc/passwd` and racing writes onto *its* shared
+blocks, then `su` — persistently rewrites a system file on disk with no undo, and
+is documented but **not bundled**. Always returns `EXPLOIT_FAIL`.
+
+Note the safety inversion versus the other reconstructed triggers: a won race
+here corrupts **file data, not kernel memory**, so there is no oops, no KASAN
+report and no panic path, and the blast radius is 4 KiB of a scratch file the
+module then deletes. `refluxfs` therefore carries safety rank **55** — far above
+`bad_epoll` (12) and `ghostlock` (11) — and `--cleanup` sweeps any
+`skeletonkey-refluxfs-*` directories left by an interrupted run.
+
+Detection gets a genuinely unusual treatment, because the obvious rule is the one
+that fails. auditd/sigma anchor on the two operations the attack cannot avoid —
+`ioctl` request **`0x40049409`** (`FICLONE`, matched exactly so it does not flood)
+and `openat` with `O_DIRECT` (`& 0x4000`) — plus the post-exploitation euid-0
+transition; falco adds the high-fidelity "reflinked a file owned by another user"
+condition. And for once the **yara** rule is the right tool for a kernel bug:
+since FIM is structurally blind here, it matches the *on-disk artifact* — a
+`passwd` file with a password-less root entry or an added uid-0 account. The
+module docs also recommend content-hash-vs-`mtime` drift monitoring, which is a
+near-zero-false-positive detector for this entire bug class.
+
+14 new `detect()` unit rows cover the backport boundaries, the 4.11 introduction
+gate, the el8/el9 upstream bases, the "newer than some entries but not all" case,
+and the no-XFS `PRECOND_FAIL` path (**148 tests total, 0 failures**).
+
+**VM-verified 2026-07-23 — the corpus's first rpm-family verification**, taking
+the empirical count to **29 of 41 CVEs**. Target: **Rocky Linux 9.8 /
+`5.14.0-687.10.1.el9_8.0.1.x86_64`** under qemu/KVM with 6 vCPUs. The stock
+GenericCloud layout needed **no provisioner changes at all** — root is
+`/dev/vda4` XFS with `reflink=1` out of the box, which is precisely why this CVE
+hits the RHEL family so broadly. `detect()` returned `VULNERABLE`, the
+rpm-family vendor-backport caveat fired, the `--active` FICLONE witness confirmed
+reflink, phase A observed `FIEMAP_EXTENT_SHARED` on a real shared extent, the
+scratch dir self-cleaned, and the source built clean on el9 gcc.
+
+The **underlying bug was separately confirmed winnable** on that kernel using a
+VM-only harness driven at the public PoC's parameters (32 writers / 8 helpers,
+60 s — `tools/verify-vm/refluxfs_verify.c`): **4 out of 4 runs won**, first
+divergence after **69, 114, 170 and 494 rounds**. A racing `O_DIRECT` write
+landed on a still-shared block and rewrote the donor's on-disk bytes — the
+arbitrary-overwrite primitive observed directly, contained to files the test user
+owned, with no oops and no dmesg output (as expected for a data-oriented bug).
+
+Worth stating plainly, because it is the whole point of the design: the shipped
+trigger **did not win** in its 2 s budget on a kernel that is provably
+vulnerable. That is intended under-driving, not a defect — and it is the concrete
+reason a non-win must **never** be recorded as "patched". Trust the version gate
+and the vendor erratum.
+
+Credit: **Qualys Threat Research Unit** (blog by **Saeed Abbasi**; the technical
+advisory credits model-assisted kernel analysis performed with **Anthropic**),
+and the upstream XFS maintainers who fixed it.
+
+---
+
 ## SKELETONKEY v0.9.13 — new LPE module: ghostlock (CVE-2026-43499)
 
 Adds **`ghostlock` — CVE-2026-43499 "GhostLock"** (VEGA / Nebula Security,

docs/VERIFICATIONS.jsonl

@@ -34,3 +34,4 @@
 {"module":"sudo_runas_neg1","verified_at":"2026-05-24T03:29:18Z","host_kernel":"4.15.0-213-generic","host_distro":"Ubuntu 18.04.6 LTS","vm_box":"generic/ubuntu1804","expect_detect":"VULNERABLE","actual_detect":"VULNERABLE","status":"match"}
 {"module":"tioscpgrp","verified_at":"2026-05-24T03:31:08Z","host_kernel":"5.4.0-26-generic","host_distro":"Ubuntu 20.04.6 LTS","vm_box":"generic/ubuntu2004","expect_detect":"VULNERABLE","actual_detect":"VULNERABLE","status":"match"}
 {"module":"dirtydecrypt","verified_at":"2026-05-24T05:16:27Z","host_kernel":"6.19.7-061907-generic","host_distro":"Ubuntu 22.04.3 LTS","vm_box":"generic/ubuntu2204","expect_detect":"VULNERABLE","actual_detect":"VULNERABLE","status":"match"}
+{"module":"refluxfs","verified_at":"2026-07-23T21:45:28Z","host_kernel":"5.14.0-687.10.1.el9_8.0.1.x86_64","host_distro":"Rocky Linux 9.8 (Blue Onyx)","vm_box":"rocky9-genericcloud/qemu-kvm","expect_detect":"VULNERABLE","actual_detect":"VULNERABLE","status":"match"}

docs/index.html

@@ -4,9 +4,9 @@
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <title>SKELETONKEY — Linux LPE corpus, VM-verified, SOC-ready detection</title>
-<meta name="description" content="One binary. 45 Linux privilege-escalation modules from 2016 to 2026. 28 of 40 CVEs empirically verified in real Linux VMs. 13 KEV-listed. 151 detection rules across auditd/sigma/yara/falco. MITRE ATT&CK and CWE annotated. --explain gives operator briefings.">
+<meta name="description" content="One binary. 46 Linux privilege-escalation modules from 2016 to 2026. 29 of 41 CVEs empirically verified in real Linux VMs. 13 KEV-listed. 151 detection rules across auditd/sigma/yara/falco. MITRE ATT&CK and CWE annotated. --explain gives operator briefings.">
 <meta property="og:title" content="SKELETONKEY — Linux LPE corpus, VM-verified">
-<meta property="og:description" content="45 Linux LPE modules; 28 of 40 CVEs empirically verified in real VMs. 151 detection rules. ATT&CK + CWE + KEV annotated.">
+<meta property="og:description" content="46 Linux LPE modules; 29 of 41 CVEs empirically verified in real VMs. 151 detection rules. ATT&CK + CWE + KEV annotated.">
 <meta property="og:type" content="website">
 <meta property="og:url" content="https://skeletonkey.netslum.io/">
 <meta property="og:image" content="https://skeletonkey.netslum.io/og.png?v=2">
@@ -56,14 +56,14 @@
   <div class="container hero-inner">
     <div class="hero-eyebrow">
       <span class="dot dot-pulse"></span>
-      v0.9.11 — released 2026-06-08
+      v0.9.14 — released 2026-07-23
     </div>
     <h1 class="hero-title">
       <span class="display-wordmark">SKELETONKEY</span>
     </h1>
     <p class="hero-tag">
-      One binary. <strong>45 Linux LPE modules</strong> covering 40 CVEs —
-      <strong>every year 2016 → 2026</strong>. 28 of 40 confirmed against
+      One binary. <strong>46 Linux LPE modules</strong> covering 41 CVEs —
+      <strong>every year 2016 → 2026</strong>. 29 of 41 confirmed against
       real Linux kernels in VMs. SOC-ready detection rules in four SIEM
       formats. MITRE ATT&amp;CK + CWE + CISA KEV annotated.
       <span class="hero-tag-pop">--explain gives a one-page operator briefing per CVE.</span>
@@ -81,8 +81,8 @@
     </div>
 
     <div class="stats-row" id="stats-row">
-      <div class="stat-chip"><span class="num" data-target="45">0</span><span>modules</span></div>
-      <div class="stat-chip stat-vfy"><span class="num" data-target="28">0</span><span>✓ VM-verified</span></div>
+      <div class="stat-chip"><span class="num" data-target="46">0</span><span>modules</span></div>
+      <div class="stat-chip stat-vfy"><span class="num" data-target="29">0</span><span>✓ VM-verified</span></div>
       <div class="stat-chip stat-kev"><span class="num" data-target="13">0</span><span>★ in CISA KEV</span></div>
       <div class="stat-chip"><span class="num" data-target="151">0</span><span>detection rules</span></div>
     </div>
@@ -227,7 +227,7 @@ uid=0(root) gid=0(root)</pre>
         <div class="bento-icon">★</div>
         <h3>CISA KEV prioritized</h3>
         <p>
-          13 of 40 CVEs in the corpus are in CISA's Known Exploited
+          13 of 41 CVEs in the corpus are in CISA's Known Exploited
           Vulnerabilities catalog — actively exploited in the wild.
           Refreshed on demand via <code>tools/refresh-cve-metadata.py</code>.
         </p>
@@ -289,12 +289,12 @@ uid=0(root) gid=0(root)</pre>
 
       <article class="bento-card bento-vfy">
         <div class="bento-icon">✓</div>
-        <h3>28 modules empirically verified</h3>
+        <h3>29 modules empirically verified</h3>
         <p>
           <code>tools/verify-vm/</code> spins up known-vulnerable
           kernels (stock distro + mainline from kernel.ubuntu.com), runs
           <code>--explain --active</code> per module, and records the
-          verdict. <strong>28 of 40 CVEs</strong> confirmed against
+          verdict. <strong>29 of 41 CVEs</strong> confirmed against
           real Linux across Ubuntu 18.04 / 20.04 / 22.04 + Debian 11 / 12
           + mainline 5.4.0-26 / 5.15.5 / 6.1.10 / 6.19.7. Records baked into the binary;
           <code>--list</code> shows ✓ per module.
@@ -309,7 +309,7 @@ uid=0(root) gid=0(root)</pre>
   <div class="container">
     <div class="section-head">
       <span class="section-tag">corpus</span>
-      <h2>40 CVEs across 10 years. ★ = actively exploited (CISA KEV).</h2>
+      <h2>41 CVEs across 10 years. ★ = actively exploited (CISA KEV).</h2>
     </div>
 
     <h3 class="corpus-h" data-color="green">
@@ -360,6 +360,7 @@ uid=0(root) gid=0(root)</pre>
       <span class="pill yellow">nft_catchall</span>
       <span class="pill yellow">bad_epoll</span>
       <span class="pill yellow">ghostlock</span>
+      <span class="pill yellow">refluxfs</span>
     </div>
 
     <p class="corpus-foot">
@@ -420,7 +421,7 @@ uid=0(root) gid=0(root)</pre>
         <div class="audience-icon">🎓</div>
         <h3>Researchers / CTF</h3>
         <p>
-          40 CVEs, 10-year span, each with the original PoC author
+          41 CVEs, 10-year span, each with the original PoC author
           credited and the kernel-range citation auditable.
           <code>--explain</code> shows the reasoning chain; detection
           rules let you practice both sides. Source is the documentation.
@@ -517,7 +518,7 @@ uid=0(root) gid=0(root)</pre>
       <div class="tl-col tl-shipped">
         <div class="tl-tag">shipped</div>
         <ul>
-          <li><strong>28 of 40 CVEs empirically verified</strong> in real Linux VMs</li>
+          <li><strong>29 of 41 CVEs empirically verified</strong> in real Linux VMs</li>
           <li><strong>kernel.ubuntu.com/mainline/</strong> kernel fetch path — unblocks pin-not-in-apt targets</li>
           <li>Per-module <code>verified_on[]</code> table baked into the binary</li>
           <li><strong>--explain mode</strong> — one-page operator briefing per CVE</li>