leviathan/SKELETONKEY
1
1
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity
Files
c55adc18400dccff1a7bc43a65fb32be8aab9df5
SKELETONKEY/core/cve_metadata.c
T
KaraZajac e46a32f11e
build / build (clang / debug) (push) Waiting to run
Details
build / build (clang / default) (push) Waiting to run
Details
build / build (gcc / debug) (push) Waiting to run
Details
build / build (gcc / default) (push) Waiting to run
Details
build / sanitizers (ASan + UBSan) (push) Waiting to run
Details
build / clang-tidy (push) Waiting to run
Details
build / drift-check (CISA KEV + Debian tracker) (push) Waiting to run
Details
build / static-build (push) Waiting to run
Details
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
2026-07-23 17:49:40 -04:00

362 lines
11 KiB
C
Raw Blame History

/*
* SKELETONKEY — CVE metadata table
*
* AUTO-GENERATED by tools/refresh-cve-metadata.py from
* docs/CVE_METADATA.json. Do not hand-edit; rerun the script.
* Sources: CISA KEV catalog + NVD CVE API 2.0.
*/
#include "cve_metadata.h"
#include <stddef.h>
#include <string.h>
const struct cve_metadata cve_metadata_table[] = {
{
.cve = "CVE-2016-5195",
.cwe = "CWE-362",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2022-03-03",
},
{
.cve = "CVE-2017-7308",
.cwe = "CWE-681",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2018-14634",
.cwe = "CWE-190",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2026-01-26",
},
{
.cve = "CVE-2019-13272",
.cwe = NULL,
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2021-12-10",
},
{
.cve = "CVE-2019-14287",
.cwe = "CWE-755",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2020-14386",
.cwe = "CWE-250",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2020-29661",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2021-22555",
.cwe = "CWE-787",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2025-10-06",
},
{
.cve = "CVE-2021-3156",
.cwe = "CWE-193",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2022-04-06",
},
{
.cve = "CVE-2021-33909",
.cwe = "CWE-190",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2021-3493",
.cwe = "CWE-270",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2022-10-20",
},
{
.cve = "CVE-2021-4034",
.cwe = "CWE-787",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2022-06-27",
},
{
.cve = "CVE-2022-0185",
.cwe = "CWE-190",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2024-08-21",
},
{
.cve = "CVE-2022-0492",
.cwe = "CWE-287",
.attack_technique = "T1611",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2026-06-02",
},
{
.cve = "CVE-2022-0847",
.cwe = "CWE-665",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2022-04-25",
},
{
.cve = "CVE-2022-25636",
.cwe = "CWE-269",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2022-2588",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2023-0179",
.cwe = "CWE-190",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2023-0386",
.cwe = "CWE-282",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2025-06-17",
},
{
.cve = "CVE-2023-0458",
.cwe = "CWE-476",
.attack_technique = "T1082",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2023-2008",
.cwe = "CWE-129",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2023-22809",
.cwe = "CWE-269",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2023-32233",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2023-3269",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2023-4622",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2024-1086",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2024-05-30",
},
{
.cve = "CVE-2024-26581",
.cwe = NULL,
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2024-50264",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2025-32462",
.cwe = "CWE-863",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2025-32463",
.cwe = "CWE-829",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = true,
.kev_date_added = "2025-09-29",
},
{
.cve = "CVE-2025-6019",
.cwe = "CWE-250",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-23111",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-31635",
.cwe = "CWE-130",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-41651",
.cwe = "CWE-367",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-43494",
.cwe = NULL,
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-43499",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-46242",
.cwe = "CWE-416",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-46243",
.cwe = "CWE-20",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-46300",
.cwe = "CWE-787",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
.cve = "CVE-2026-46333",
.cwe = "CWE-269",
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
{
/* NVD had published no CWE for this CVE at time of writing
* (disclosed 2026-07-22); SKELETONKEY's own reading is CWE-362
* (race) yielding CWE-367 (TOCTOU) — see the module MODULE.md.
* This field mirrors NVD, so it stays NULL until NVD classifies
* it and the refresh script fills it in. */
.cve = "CVE-2026-64600",
.cwe = NULL,
.attack_technique = "T1068",
.attack_subtechnique = NULL,
.in_kev = false,
.kev_date_added = "",
},
};
const size_t cve_metadata_table_len =
sizeof(cve_metadata_table) / sizeof(cve_metadata_table[0]);
const struct cve_metadata *cve_metadata_lookup(const char *cve)
{
if (!cve) return NULL;
for (size_t i = 0; i < cve_metadata_table_len; i++) {
if (strcmp(cve_metadata_table[i].cve, cve) == 0)
return &cve_metadata_table[i];
}
return NULL;
}
Reference in New Issue View Git Blame Copy Permalink