19 Commits

Author	SHA1	Message	Date
KaraZajac	65588599ff	dirty_cow: verify end-to-end on 4.8.0; robust su helper (dirty_pipe too) ... Verified the dirty_cow fix end-to-end on a genuinely Dirty-COW-vulnerable mainline 4.8.0 kernel (installed the kernel.ubuntu.com 4.8.0 deb on a 16.04 image + virtio-rng for entropy). A standalone built verbatim from the module's primitive + escalation raced root's password field, authenticated as root over a pty, planted a root-owned setuid bash, and left /etc/passwd byte-identical. (The full skeletonkey binary won't compile on xenial's 4.4-era uapi headers — unrelated nft_* modules use newer kernel constants — so the verbatim standalone stands in for --exploit dirty_cow there.) Robustness fix (both dirty_cow AND dirty_pipe): the su-over-pty step now POLLS for the password prompt and hard-caps at 20s. The previous fixed-delay write raced su's prompt setup and HUNG on xenial; without a cap that would block the revert and leave /etc/passwd poisoned. Now su can never hang the module, and the revert always runs. Also: netfilter_xtcompat now includes <linux/if.h> for IFNAMSIZ (ip_tables.h doesn't pull it transitively on older kernel headers, e.g. Ubuntu 16.04) — a real portability fix surfaced by building on xenial. Host build + unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 23:26:12 -04:00
KaraZajac	678a37b2f5	dirty_pipe: fix 3 bugs — working CVE-2022-0847 exploit that lands real root ... Verified out-of-band on a genuinely pre-fix mainline 5.16.0 kernel (installed from kernel.ubuntu.com onto the jammy image; every cached cloud image was pre-5.8 or backport-patched). `skeletonkey --exploit dirty_pipe` (uid 1000) -> EXPLOIT_OK + a -rwsr-xr-x root:root bash, and /etc/passwd is byte-identical afterward. Three real bugs in the shipped module: 1. Wrong escalation: it flipped the CALLER's UID field to "0000" and ran `su <self>`, which still demands the caller's password -> never rooted anything. 2. False EXPLOIT_OK: it execlp'd su, so the dispatcher's "exec transferred -> clean exit = OK" path reported success even on su's auth failure. 3. Dangerous revert: revert_passwd_page_cache() used drop_caches, which needs root -> as an unprivileged caller it left the running system's /etc/passwd page cache corrupted (broke sshd user resolution in testing). Rewrite (AabyssZG-style, self-contained + verifying): - overwrite ROOT's password field with a known $6$ crypt hash via the Dirty Pipe primitive (the longer hash clobbers into following lines, transiently); - authenticate as root over a pty with the matching password (su reads the password from the controlling tty, not stdin); - plant a root-owned proof + setuid bash; judge success ONLY by stat()'ing the root-owned artifact; - revert the page cache by writing the saved original bytes back through the Dirty Pipe primitive itself — no root, no drop_caches, nothing persists. cleanup() re-reverts idempotently. Unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 22:50:39 -04:00
KaraZajac	82ba6e0d08	sudo_samedit: working CVE-2021-3156 (Baron Samedit) exploit — lands real root ... The shipped module drove a structural sudoedit trigger with no heap-grooming offsets and honestly reported EXPLOIT_FAIL. Ported blasty's proven technique: the `sudoedit -s` set_cmnd() unescape overflow overwrites a glibc NSS service_user, so the subsequent NSS lookup dlopen's an attacker-planted libnss_X/'P0P_SH3LLZ_ .so.2' from CWD, whose constructor runs while sudo is still root. Implementation follows the corpus's runtime-compile pattern: build the NSS payload on the target (unique -DSK_PROOF/-DSK_ROOTBASH), lay out the libnss_X/ dir, exec sudoedit with the crafted argv (AAAA..\ / \ / BBBB..\) and env (null_stomp × "\\", "X/P0P_SH3LLZ_", padded LC_ALL) from that CWD, and verify root by stat()'ing the root-owned artifacts — never self-report. Grooming lengths are libc-family specific (Ubuntu 56/54/63/212, Debian 64/49/60/214); a null_stomp_len ±8 sweep (blasty brute.sh's axis) is the fallback for drift. Verified out-of-band on Ubuntu 18.04.0 / sudo 1.8.21p2 / libc-2.27, as uid 1000 (non-sudoer — the overflow precedes the sudoers/password check): `skeletonkey --exploit sudo_samedit` -> EXPLOIT_OK + a -rwsr-xr-x root:root bash, primary lengths landing first try. Gated on cc + sudoedit; cleanup() removes artifacts and the scratch build dir. Unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 22:22:11 -04:00
KaraZajac	635f7d2d24	ptrace_traceme: working CVE-2019-13272 exploit — lands real root (x86_64) ... The bundled sequence had the mechanism backwards (it PTRACE_ATTACHed the now-root parent) and never rooted anything. Replaced it with the proven Jann Horn (Project Zero #1903) / bcoles technique: - a "middle" process execs setuid pkexec (euid 0 for a window); - its child spins until it sees middle is euid 0, calls PTRACE_TRACEME (recording middle's ROOT creds as ptracer_cred — the bug), then execs pkexec itself. The traced setuid exec is NOT degraded because ptracer_cred is root, so the child becomes real root, still traced; - staged execveat() self-re-exec injects the payload as root. The staged self-re-exec needs the exploit to exist as its own binary with an argv[0] stage dispatcher, so the proven PoC is embedded verbatim (ptrace_helper_src.h — only spawn_shell() changed, to plant a root-owned proof + setuid bash instead of only an interactive shell), compiled on the target at runtime with unique -DSK_PROOF/-DSK_ROOTBASH paths, run, and verified by stat()'ing the root-owned artifacts (never self-report). Verified out-of-band on Ubuntu 18.04.0 / 4.15.0-50: `skeletonkey --exploit ptrace_traceme` as uid 1000 -> EXPLOIT_OK + a -rwsr-xr-x root:root bash. Real-world precondition, honestly reported: pkexec must authorize an auto-discovered implicit-active=yes helper, which needs an active local session (desktop) or a permissive polkit policy; over inactive ssh it returns "Not authorized" and the module reports EXPLOIT_FAIL with that diagnosis. Gated on a C compiler + pkexec; x86_64 only (register-level injection). cleanup() removes the artifacts. Unit harness green (33 + 115). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 22:14:19 -04:00
KaraZajac	cd9bea6399	offsets: fix env override being wiped under kptr_restrict (unblocks all full-chains) ... skeletonkey_offsets_resolve() runs sources in priority order: env vars first, then /proc/kallsyms. On any default host kallsyms returns all-zero addresses (kptr_restrict), and parse_symfile treated "all zero" by UNCONDITIONALLY zeroing modprobe_path/init_task — clobbering the values apply_env had just set from SKELETONKEY_MODPROBE_PATH / SKELETONKEY_INIT_TASK. Net effect: the documented env-var offset override silently did nothing, so every --full-chain kernel primitive reported "offsets couldn't be resolved" even when correct offsets were supplied. Now the all-zero path only clears fields it tagged OFFSETS_FROM_KALLSYMS itself, preserving env (and table/System.map) values. Verified on Ubuntu 22.04.0 / 5.15.0-25: with SKELETONKEY_MODPROBE_PATH set, the resolver now reports "modprobe_path=0x... (env)", the modprobe_path finisher engages, and nf_tables' pipapo arb-write fires. (nf_tables itself still returns an honest EXPLOIT_FAIL: the reconstructed double-free arb-write doesn't reliably land the write yet — recorded in docs/EXPLOITED.md.) This fix is the prerequisite for verifying any of the ~13 primitive full-chains. Unit harness green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 21:41:02 -04:00
KaraZajac	6960d2076d	docs: record sudo_host (CVE-2025-32462) confirmed landing root ... sudo_host works as shipped — no code change. VM-verified on Ubuntu 22.04.0 / sudo 1.9.9-1ubuntu2: with a host-restricted sudoers rule (scoped to a host that is neither the current hostname nor ALL) and a resolvable host name, `sudo -h <host> <cmd>` runs as uid 0 (the -h/--host authorization-logic flaw). Module confirmed EXPLOIT_OK with a real uid=0 witness and popped a root shell. The only preconditions are environmental (the host-restricted rule, common with fleet-wide/LDAP/SSSD sudoers, supplied via SKELETONKEY_SUDO_HOST) — not a bug. VERIFICATIONS.jsonl + EXPLOITED.md updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 21:34:24 -04:00
KaraZajac	70972e0c9d	sudoedit_editor: fix CVE-2023-22809 exploit to actually land root ... The module built the right EDITOR="helper -- /etc/passwd" injection but failed two ways, both now fixed (VM-verified root on Ubuntu 22.04.0 / sudo 1.9.9-1ubuntu2): 1. Writable-CWD guard: sudoedit refuses to edit any file whose parent dir is user-writable. The injected "--" is resolved relative to CWD, so running from home/tmp made sudoedit abort "--: editing files in a writable directory" before the editor ran. Fix: chdir("/") in the sudoedit child. 2. Wrong tmp copy: sudoedit hands the editor one tmp copy per file, named <basename>.XXXXXX. The helper wrote argv[argc-1] — the sudoers-authorized COVER file (e.g. motd), not the target. Fix: the helper now matches the target's basename prefix (passed via SKEL_TARGET) to pick the right copy. Result: /etc/passwd gains a skel::0:0 row; `su skel` -> uid=0(root). docs/EXPLOITED.md + VERIFICATIONS.jsonl updated. Unit harness green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 21:32:44 -04:00
KaraZajac	58b44ebc43	docs: record overlayfs_setuid (FUSE port needed) + sudoedit_editor findings ... overlayfs_setuid (CVE-2023-0386) investigated on Ubuntu 22.04.0 / 5.15.0-25 (genuinely vulnerable): the non-FUSE chown copy-up yields upper/file owned by uid 1000 (no escalation), and overlay refuses a userns-mounted FUSE lowerdir with ENOSYS (plain overlay-in-userns works). A working exploit must mount FUSE in the init ns via the setuid fusermount helper (fd-passing protocol) then overlay in the userns — a substantial dedicated port. A raw /dev/fuse server was written and reverted after hitting the ENOSYS wall. sudoedit_editor (CVE-2023-22809) on sudo 1.9.9 returns EXPLOIT_FAIL — the SUDO_EDITOR/-- arg injection reaches sudoedit's writable-dir guard; needs target-file tuning and module debugging. Tractable next. Ledger + VERIFICATIONS.jsonl updated. No code change (overlayfs_setuid reverted to baseline; not committing a second non-working variant). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 20:34:58 -04:00
KaraZajac	8c45b2beb8	cgroup_release_agent: fix uid_map (read uid pre-unshare) + add CLONE_NEWCGROUP ... Two real bugs found via VM verification (Ubuntu 20.04.0 / 5.4.0-26): 1. uid_map EPERM: the child captured getuid()/getgid() AFTER unshare(CLONE_NEWUSER), where they return 65534 (nobody, the initial unmapped id), so it wrote "0 65534 1" to uid_map — rejected with EPERM. Now the outer uid/gid are read BEFORE unshare, yielding the correct "0 <uid> 1" single-uid self-map. (overlayfs got this right, which is why it worked; this module didn't.) 2. mount EPERM: the unprivileged cgroup-v1 mount needs a private cgroup namespace. Added CLONE_NEWCGROUP (with a fallback) — mounting an unused v1 controller then succeeds. With both fixed the userns+cgroupns+mount setup is correct. Note: on a stock systemd host every v1 controller is already mounted (its release_agent is owned by init-root and unwritable from the userns) and creating a fresh named hierarchy is refused, so a bare unprivileged user cannot own release_agent — CVE-2022-0492 is reachable in a container context (CAP_SYS_ADMIN / an ownable cgroup), consistent with the module's "host root from rootless container" framing. Verified out-of-band; see docs/EXPLOITED.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 20:15:51 -04:00
KaraZajac	59cc2be065	ptrace_traceme: stop the false EXPLOIT_OK; add exploit-verification ledger ... ptrace_traceme reported EXPLOIT_OK while obtaining no root on a genuinely vulnerable host (Ubuntu 18.04.2 / 4.15.0-50). The bundled ptrace sequence is a non-working placeholder — it PTRACE_ATTACHes to the tracer, which by then has reparented to init, so the attach fails EPERM; the parent then execve'd the setuid trigger and the dispatcher's exec-transfer path reported a false OK. Now the parent fires the trigger in a grandchild, stays alive, and verifies euid==0 before claiming success — otherwise honest EXPLOIT_FAIL with a pointer to the real CVE-2019-13272 technique (Jann Horn / bcoles) that still needs porting. Adds docs/EXPLOITED.md: the exploit-verification ledger (root witnessed OUT OF BAND, not from the module's self-report). Confirmed landing root: refluxfs, overlayfs, pwnkit (after its gconv fix), sudo_runas_neg1. Needs PoC ports: ptrace_traceme, overlayfs_setuid (CVE-2023-0386 FUSE copy-up), sudo_samedit (heap), cgroup_release_agent. ~30 modules still exploit-untested. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 19:59:48 -04:00
KaraZajac	24b839eccf	pwnkit: fix the gconv re-injection layout so the exploit actually lands root ... The exploit reported EXPLOIT_OK but did NOT get root on a genuinely vulnerable target (Ubuntu 20.04.0, polkit 0.105-26ubuntu1). pkexec printed "Cannot run program pwnkit" + glibc "Could not open converter from UTF-8 to PWNKIT" and no root shell was obtained — a false positive from the dispatcher's "execve transferred → clean exit = OK" path. Root cause: the module built workdir/pwnkit/{gconv-modules,PWNKIT.so} correctly but omitted the two pieces that make the GCONV_PATH trick fire: 1. a directory literally named "GCONV_PATH=." containing an executable "pwnkit", so pkexec's g_find_program_in_path() resolves argv[0] and RE-INJECTS GCONV_PATH=./pwnkit into the sanitised environment; and 2. chdir(workdir) so the re-injected relative "./pwnkit" resolves to the gconv dir. It also set an absolute GCONV_PATH=<workdir>/pwnkit directly in envp, which pkexec strips (GCONV_PATH is on polkit's blacklist) — removed. VM-verified after the fix on Ubuntu 20.04.0 / 5.4.0-26 (polkit 0.105-26ubuntu1): unprivileged sk -> uid=0(root), confirmed out-of-band (wrote /root/, read /etc/shadow). overlayfs (CVE-2021-3493) also confirmed landing root on the same host; sudo_samedit returns an honest EXPLOIT_FAIL there (heap not landed). Found via the new qemu exploit-verification sweep (root confirmed out-of-band, not from the module's self-report). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0118iUgHY44hdRtANgyCmu7y	2026-07-23 19:40:04 -04:00
KaraZajac	e46a32f11e	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
KaraZajac	fa0228df9b	release v0.9.3: CVE metadata refresh (KEV 10→12) + dirtydecrypt bug fix ... CVE metadata refresh: - Added 8 entries to core/cve_metadata.c for the v0.8.0 + v0.9.0 module CVEs. Two are CISA-KEV-listed: - CVE-2018-14634 mutagen_astronomy (2026-01-26, CWE-190) - CVE-2025-32463 sudo_chwoot (2025-09-29, CWE-829) - Populated via direct curl when refresh-cve-metadata.py's Python urlopen hung on CISA's HTTP/2 endpoint for ~55 min — same data, different transport. dirtydecrypt module bug fix: - dd_detect() was wrongly gating 'predates the bug' on kernel < 7.0 - Per NVD CVE-2026-31635: bug entered at 6.16.1 stable; vulnerable through 6.18.22 / 6.19.12 / 7.0-rc7; fixed at 6.18.23 / 6.19.13 / 7.0 - Fix: predates-gate now uses 6.16.1; patched_branches[] adds {6,18,23} - Re-verified: dirtydecrypt now correctly returns VULNERABLE on mainline 6.19.7 instead of OK. Previously a false negative on real vulnerable kernels. Footer goes from '10 in CISA KEV' to '12 in CISA KEV'. Verified count stays at 28 but dirtydecrypt's record is now a TRUE VULNERABLE match (was OK match).	2026-05-24 01:17:58 -04:00
KaraZajac	66cca39a55	release v0.9.2: dirtydecrypt verified on mainline 6.19.7 (22 → 28) ... Verifies CVE-2026-31635 dirtydecrypt's OK path on a kernel that predates the bug: 'kernel predates the rxgk RESPONSE-handling code added in 7.0' — match. Confirms detect() doesn't false-positive on older 6.x kernels. Attempted fragnesia (CVE-2026-46300) but mainline 7.0.5 .debs depend on libssl3t64 / libelf1t64 (t64-transition libs from Ubuntu 24.04+ / Debian 13+). No Parallels-supported Vagrant box ships those yet — dpkg --force-depends leaves the kernel package in iHR state with no /boot/vmlinuz. Marked manual: true with rationale. Verifier infrastructure: pin-mainline now uses dpkg --force-depends as a fallback so partial-install state can at least be inspected.	2026-05-24 00:03:35 -04:00
KaraZajac	8ac041a295	release v0.9.1: VM verification sweep 22 → 27 ... Five more CVEs empirically confirmed end-to-end against real Linux VMs: - CVE-2019-14287 sudo_runas_neg1 (Ubuntu 18.04 + sudoers grant) - CVE-2020-29661 tioscpgrp (Ubuntu 20.04 pinned to 5.4.0-26) - CVE-2024-26581 nft_pipapo (Ubuntu 22.04 + mainline 5.15.5) - CVE-2025-32463 sudo_chwoot (Ubuntu 22.04 + sudo 1.9.16p1 from source) - CVE-2025-6019 udisks_libblockdev (Debian 12 + udisks2 + polkit rule) Required real plumbing work: - Per-module provisioner hook (tools/verify-vm/provisioners/<module>.sh) - Two-phase provision in verify.sh (prep → reboot if needed → verify) fixes silent-fail where new kernel installed but VM never rebooted - GRUB_DEFAULT pinning in both pin-kernel and pin-mainline blocks (kernel downgrades like 5.4.0-169 → 5.4.0-26 now actually boot the target) - Old-mainline URL fallback in pin-mainline (≤ 4.15 debs at /v$KVER/ not /amd64/) mutagen_astronomy marked manual: true — mainline 4.14.70 kernel-panics on Ubuntu 18.04's rootfs ('Failed to execute /init (error -8)' — kernel config mismatch). Genuinely needs a CentOS 6 / Debian 7 image.	2026-05-23 23:35:02 -04:00
KaraZajac	312e7d89b5	verify-vm: kernel.ubuntu.com mainline integration — 22 modules verified ... Unblocks the 4 previously-PIN_FAIL modules by adding a fallback path to kernel.ubuntu.com/mainline/ for any kernel no longer in apt. Adds 4 more matches to the verified_on table for a total of 22 modules confirmed against real Linux VMs: af_unix_gc ubuntu2204 + mainline 5.15.5 match nf_tables ubuntu2204 + mainline 5.15.5 match nft_set_uaf ubuntu2204 + mainline 5.15.5 match stackrot ubuntu2204 + mainline 6.1.10 match Mechanism: tools/verify-vm/Vagrantfile — new 'pin-mainline-<X.Y.Z>' shell provisioner. Fetches the directory index at https://kernel.ubuntu.com/mainline/v<X.Y.Z>/amd64/, parses out the 4 canonical .deb filenames (linux-headers _all, linux-headers -generic _amd64, linux-image-unsigned -generic _amd64, linux-modules -generic _amd64; skips lowlatency), downloads them, runs 'dpkg -i' + 'update-grub', and prints a reboot hint. Mainline package version like '5.15.5-051505' sorts ABOVE Ubuntu's stock '5.15.0-91' in debian-version-compare (numeric 51505 > 91), so update-grub puts it at the top of the boot menu and the next 'vagrant reload' lands on it automatically. uname then reports '5.15.5-051505-generic' which our parser sees as 5.15.5 → in our kernel_range table's vulnerable window → empirical VULNERABLE. tools/verify-vm/verify.sh — new SKK_VM_MAINLINE_VERSION env passed to the Vagrantfile. Reload trigger now also fires when uname doesn't match the mainline target. tools/verify-vm/targets.yaml — new 'mainline_version' field on the 4 PIN_FAIL targets. kernel_pkg is left empty; mainline_version drives the fetch. Picked 5.15.5 (Nov 2021) for the 5.15-line CVEs and 6.1.10 (Feb 2023) for stackrot — both below every relevant backport. Final sweep status (22 of 26 CVEs): ✓ MATCHES (22): pwnkit, cgroup_release_agent, netfilter_xtcompat, fuse_legacy, nft_fwd_dup, entrybleed, overlayfs, overlayfs_setuid, sudoedit_editor, ptrace_traceme, sudo_samedit, af_packet, pack2theroot, cls_route4, nft_payload, af_packet2, sequoia, dirty_pipe, nf_tables, af_unix_gc, nft_set_uaf, stackrot 🚫 NOT VERIFIED (4 — flagged in targets.yaml with rationale): vmwgfx — VMware-guest only; no public Vagrant box covers it dirtydecrypt — needs Linux 7.0; not shipping as any distro kernel fragnesia — needs Linux 7.0; same dirty_cow — needs ≤ 4.4 kernel; older than every supported Vagrant box (would need a custom image) copy_fail_family entries verified indirectly via the shared infrastructure tests in the kernel_range unit-test harness. The 22 records are baked into core/verifications.c and surface in --list (VFY ✓ column), --module-info (--- verified on --- section), --explain (VERIFIED ON section), and JSON output (verified_on array). 22/26 CVEs is the new trust signal; with the mainline fetch path production-ready, additional pin targets can be added to targets.yaml without code changes.	2026-05-23 17:35:13 -04:00
KaraZajac	2c131df1bf	verify-vm sweep complete: 18 modules confirmed across 5 Linux distros ... Full sweep results: MATCHES (18 — empirically confirmed in real Linux VMs): pwnkit ubuntu2004 5.4.0-169 VULNERABLE cgroup_release_agent debian11 5.10.0-27 VULNERABLE netfilter_xtcompat debian11 5.10.0-27 VULNERABLE fuse_legacy debian11 5.10.0-27 VULNERABLE nft_fwd_dup debian11 5.10.0-27 VULNERABLE entrybleed ubuntu2204 5.15.0-91 VULNERABLE overlayfs ubuntu2004 5.4.0-169 VULNERABLE overlayfs_setuid ubuntu2204 5.15.0-91 VULNERABLE sudoedit_editor ubuntu2204 5.15.0-91 PRECOND_FAIL (no sudoers grant) ptrace_traceme ubuntu1804 4.15.0-213 VULNERABLE sudo_samedit ubuntu1804 4.15.0-213 VULNERABLE af_packet ubuntu1804 4.15.0-213 OK (4.15 is post-fix) pack2theroot debian12 6.1.0-17 PRECOND_FAIL (no PackageKit installed) cls_route4 ubuntu2004 5.15.0-43 VULNERABLE nft_payload ubuntu2004 5.15.0-43 VULNERABLE af_packet2 ubuntu2004 5.4.0-26 VULNERABLE sequoia ubuntu2004 5.4.0-26 VULNERABLE dirty_pipe ubuntu2204 5.15.0-91 OK (silently backported) PIN_FAIL (4 — targeted HWE kernels no longer in apt; needs kernel.ubuntu.com mainline integration, deferred): nf_tables wanted ubuntu2204 + 5.15.0-43-generic af_unix_gc wanted ubuntu2204 + 5.15.0-43-generic stackrot wanted ubuntu2204 + 6.1.0-13-generic nft_set_uaf wanted ubuntu2204 + 5.19.0-32-generic MANUAL / SPECIAL TARGETS (5 — flagged in targets.yaml): vmwgfx — VMware-guest only; no Vagrant box covers it dirtydecrypt — needs Linux 7.0 (not shipping yet) fragnesia — needs Linux 7.0 (not shipping yet) dirty_cow — needs <= 4.4 (older than every supported Vagrant box) copy_fail family — multi-module family verification deferred Several findings the active-probe path surfaced vs version-only checks: - dirty_pipe (ubuntu2204): version-only check would say VULNERABLE (kernel 5.15.0 < 5.15.25 backport in our table), but Ubuntu has silently backported the fix into the -91 patch level. --active probe correctly identified the primitive as blocked → OK. - af_packet (ubuntu1804): the bug was fixed in 4.10.6 mainline + 4.9.18 backport. Ubuntu 18.04's stock 4.15.0 is post-fix — detect() correctly returns OK. The targets.yaml entry was originally wrong; fixed now. - sudoedit_editor: version-wise the host is vulnerable (sudo 1.9.9), but the bug requires an actual sudoedit grant in /etc/sudoers — and the default Vagrant user has none. detect() correctly returns PRECOND_FAIL ('vuln version present, no grant to abuse'). Same as one of our unit tests. - pack2theroot: needs an active PackageKit daemon on the system bus. Debian 12's generic cloud image is server-oriented and omits PackageKit. detect() correctly returns PRECOND_FAIL. Provisioning PackageKit in a follow-up Vagrant step would unblock the VULNERABLE path verification. Plumbing fixes that landed in the sweep: - core/nft_compat.h — NFTA_CHAIN_FLAGS (kernel 5.7) + NFTA_CHAIN_ID (5.13). Without these, nft_fwd_dup fails to compile against Ubuntu 18.04's 4.15-era nf_tables uapi, which blocked the entire skeletonkey binary from building on that box and prevented verification of ptrace_traceme / sudo_samedit / af_packet. - tools/verify-vm/Vagrantfile — 'privileged: false' on the build-and-verify provisioner. Vagrant's default runs as root; pack2theroot's detect() short-circuits with 'already root — nothing to do' when running as uid 0, which would invalidate every euid-aware module's verification. - tools/verify-vm/targets.yaml — corrected expectations for af_packet (stock 18.04 4.15 is post-fix), pack2theroot (no PackageKit on server cloud image), sudoedit_editor (no sudoers grant), and dirty_pipe (silent Ubuntu backport). - tools/refresh-verifications.py — dedup key changed from (module, vm_box, host_kernel, expect_detect) to (module, vm_box, host_kernel). When an expectation is corrected mid-sweep, the new record cleanly supersedes the old one instead of accumulating. The verifier loop is now production-ready and the trust signal in --list / --module-info / --explain reflects 18 modules confirmed against real Linux. Next-step bucket: - kernel.ubuntu.com mainline integration → unblock 4 PIN_FAIL pins. - Optional PackageKit provisioner on debian12 → unblock pack2theroot VULNERABLE path.	2026-05-23 16:29:50 -04:00
KaraZajac	48d5f15828	verify-vm sweep: 13 modules confirmed end-to-end + Vagrant fixes ... Sweep results across 3 phases: Phase 1 (no-pin, cached boxes) — 4/5 match: entrybleed ubuntu2204 5.15.0-91-generic match overlayfs ubuntu2004 5.4.0-169-generic match overlayfs_setuid ubuntu2204 5.15.0-91-generic match nft_fwd_dup debian11 5.10.0-27-amd64 match sudoedit_editor ubuntu2204 MISMATCH (no sudoers grant — expected-fix below) Phase 2 (new boxes ubuntu1804 + debian12) — 0/4 match: ptrace_traceme \ sudo_samedit \ all FAILED to build: nft_fwd_dup needs af_packet / NFTA_CHAIN_FLAGS (kernel 5.7), not in 4.15 uapi pack2theroot / pack2theroot also hit 'already root' early-exit (running as root via vagrant provision's default privileged shell) Phase 3 (kernel-pinned) — 4/8 match: cls_route4 ubuntu2004 + 5.15.0-43 HWE match nft_payload ubuntu2004 + 5.15.0-43 HWE match af_packet2 ubuntu2004 + 5.4.0-26 (still in apt!) match sequoia ubuntu2004 + 5.4.0-26 match nf_tables, af_unix_gc, stackrot, nft_set_uaf — PIN_FAIL (target kernels not in apt; need kernel.ubuntu.com mainline integration — deferred) Total: 13 modules verified end-to-end against real Linux VMs, covering kernels 5.4 / 5.10 / 5.15 / 5.4-HWE / 5.15-HWE across Ubuntu 18.04/20.04/22.04 + Debian 11/12. Three fixes for the next retry pass: 1. core/nft_compat.h — added NFTA_CHAIN_FLAGS (kernel 5.7) and NFTA_CHAIN_ID (kernel 5.13). Without these, nft_fwd_dup fails to compile on Ubuntu 18.04's 4.15-era nf_tables uapi, which blocks the entire skeletonkey build (and thus blocks ALL verifications on that box). 2. tools/verify-vm/Vagrantfile — build-and-verify provisioner now runs unprivileged (privileged: false) so detect()s that gate on 'are you already root?' don't short-circuit. pack2theroot's 'already root — nothing to do' was the motivating case; logging 'id' upfront will make this easier to diagnose next time. 3. tools/verify-vm/targets.yaml — sudoedit_editor's expectation updated from VULNERABLE to PRECOND_FAIL. Ubuntu 22.04 ships sudo 1.9.9 (vulnerable version), but the default 'vagrant' user has no sudoedit grant in /etc/sudoers, so detect() correctly short-circuits ('vuln version present, no grant to abuse'). Provisioning a grant before verifying would re-open the VULNERABLE path; deferred. Next: re-sweep the 5 failed modules (ptrace_traceme, sudo_samedit, af_packet, pack2theroot, sudoedit_editor) and pull the 4 PIN_FAIL ones into a 'requires mainline kernel' bucket in targets.yaml.	2026-05-23 16:22:10 -04:00
KaraZajac	67d091dd37	verified_on table — 5 modules empirically confirmed in real VMs ... Closes the loop opened by tools/verify-vm/: every JSON verification record now persists into docs/VERIFICATIONS.jsonl, gets folded into the embedded core/verifications.c lookup table, and surfaces in --list / --module-info / --explain / --scan --json. New: docs/VERIFICATIONS.jsonl Append-only store. One JSON record per verify.sh run. Records carry module, ISO timestamp, host_kernel, host_distro, vm_box, expected vs actual verdict, and match status. 6 lines today (5 unique after dedup; the extra is dirty_pipe's pre-correction MISMATCH that surfaced the silent-backport finding — kept in the JSONL for history, deduped out of the C table). New: tools/refresh-verifications.py Parses VERIFICATIONS.jsonl, dedupes to latest per (module, vm_box, host_kernel), generates core/verifications.c with a static array + lookup functions: verifications_for_module(name, &count_out) verifications_module_has_match(name) --check mode for CI drift detection. New: core/verifications.{h,c} Embedded record table. Lookup is O(corpus); we have <50 records. skeletonkey.c surfacing: - --list: new 'VFY' column shows ✓ for modules with >=1 'match' record. Five modules show ✓ today (pwnkit, cgroup_release_agent, netfilter_xtcompat, fuse_legacy, dirty_pipe). - --module-info: new '--- verified on ---' section enumerates every record with date / distro / kernel / vm_box / status. Modules with zero records get a 'run tools/verify-vm/verify.sh <name>' hint. - --explain: new 'VERIFIED ON' section in the operator briefing. - --scan --json / --module-info --json: 'verified_on' array of record objects per module. Verification records baked in: pwnkit Ubuntu 20.04.6 LTS 5.4.0-169 match (polkit 0.105) cgroup_release_agent Debian 11 (bullseye) 5.10.0-27 match netfilter_xtcompat Debian 11 (bullseye) 5.10.0-27 match fuse_legacy Debian 11 (bullseye) 5.10.0-27 match dirty_pipe Ubuntu 22.04.3 LTS 5.15.0-91 match (OK; silent backport) The dirty_pipe record is particularly informative: stock Ubuntu 22.04 ships 5.15.0-91-generic. Our version-only kernel_range check would say VULNERABLE (5.15.0 < 5.15.25 backport in our table). The --active probe writes a sentinel via the dirty_pipe primitive then re-reads; on this host the primitive is blocked → sentinel doesn't land → verdict OK. Ubuntu silently backports CVE fixes into the patch level (-91 here) without bumping uname's X.Y.Z. The targets.yaml entry was updated from 'expect: VULNERABLE' to 'expect: OK' to reflect what the active probe definitively determined; the original VULNERABLE expectation is preserved in the JSONL history as a demonstration of why we ship an active-probe path at all (this is the verified-vs- claimed bar in action). Plumbing fixes that landed in the same loop: - core/nft_compat.h — conditional defines for newer-kernel nft uapi constants (NFT_CHAIN_HW_OFFLOAD, NFTA_VERDICT_CHAIN_ID, etc.) that aren't in Ubuntu 20.04's pre-5.5 linux-libc-dev. Without this, nft_* modules failed to compile inside the verifier guest. Included from each nft module after <linux/netfilter/nf_tables.h>. - tools/verify-vm/Vagrantfile — wrap config in c.vm.define so each module gets its own tracked machine; disable Parallels Tools auto-install (fails on older guest kernels); translate underscores in guest hostname to hyphens (RFC 952). - tools/verify-vm/verify.sh — explicit 'vagrant rsync' before 'vagrant provision build-and-verify' (vagrant only auto-rsyncs on fresh up, not on already-running VMs); fix verdict-grep regex to tolerate Vagrant's 'skk-<module>:' line prefix + '|| true' so a grep miss doesn't trigger set-e+pipefail; append JSON record to docs/VERIFICATIONS.jsonl on every run. - tools/verify-vm/targets.yaml — dirty_pipe retargeted from ubuntu2004 + pinned 5.13.0-19 (no longer in 20.04's apt) to ubuntu2204 stock 5.15.0-91 (apt-installable + exercises the active-probe-overrides-version-check path). What's next for the verifier: - Mainline kernel.ubuntu.com integration so we can actually pin arbitrary historical kernels (currently the pin path only works with apt-installable packages). - Sweep the remaining ~18 verifiable modules and accumulate records. - Per-module verified_on counts in --explain header.	2026-05-23 15:46:14 -04:00