Files

T

leviathan f792a3c4a6 verify-vm: close the loop — first successful end-to-end VM verification

Five fixes that landed us at a working 'verify.sh <module> -> JSON
verification record' loop. Tested with pwnkit on
generic/ubuntu2004 / Ubuntu 20.04.6 LTS / 5.4.0-169-generic.

1. core/nft_compat.h — shim header that conditionally defines newer-
   kernel nft uapi constants that aren't in older distro headers:
     NFT_CHAIN_HW_OFFLOAD     kernel 5.5
     NFT_CHAIN_BINDING        kernel 5.9
     NFTA_VERDICT_CHAIN_ID    kernel 5.14
     NFTA_SET_DESC_CONCAT     kernel 5.6
     NFTA_SET_EXPR            kernel 5.12
     NFTA_SET_EXPRESSIONS     kernel 5.16
     NFTA_SET_ELEM_KEY_END    kernel 5.6
     NFTA_SET_ELEM_EXPRESSIONS kernel 5.16
   Numeric values are stable kernel ABI; the target vulnerable kernel
   understands them at runtime regardless of the build host's headers.
   Without this, nf_tables / nft_fwd_dup / nft_payload / nft_set_uaf
   modules fail to compile on Ubuntu 20.04's libc-dev (5.4 uapi).

2. modules/{nf_tables, nft_fwd_dup, nft_payload, nft_set_uaf}/
   skeletonkey_modules.c — each #includes the new compat shim after
   <linux/netfilter/nf_tables.h>.

3. tools/verify-vm/Vagrantfile — wrap config in 'c.vm.define host do
   |m| ... end' block so 'vagrant up <skk-MODULE>' finds the machine.
   (Earlier without define block, vagrant always treated the Vagrantfile
   as a single anonymous machine.) Also disable Parallels Tools auto-
   install — it fails on Ubuntu 20.04's 5.4 kernel ('current Linux
   kernel version is outdated and not supported by latest tools'); we
   use rsync sync_folder over plain SSH which doesn't need the tools.

4. tools/verify-vm/verify.sh — explicit 'vagrant rsync' before
   'vagrant provision build-and-verify' so the source tree gets synced
   even on already-running VMs (vagrant up runs rsync automatically;
   vagrant provision does not).

5. tools/verify-vm/verify.sh — fix verdict parser. Vagrant prefixes
   provisioner stdout with the VM name ('    skk-pwnkit: VERDICT:
   VULNERABLE'), so the previous '^VERDICT: ' regex never matched.
   New grep allows the prefix; added '|| true' so a grep miss doesn't
   trigger set-e+pipefail and silently exit the script before the JSON
   verification record gets emitted.

First successful verification record:
  {
    "module": "pwnkit",
    "verified_at": "2026-05-23T19:26:02Z",
    "host_kernel": "5.4.0-169-generic",
    "host_distro": "Ubuntu 20.04.6 LTS",
    "vm_box": "generic/ubuntu2004",
    "expect_detect": "VULNERABLE",
    "actual_detect": "VULNERABLE",
    "status": "match"
  }

SKELETONKEY correctly identifies polkit 0.105 on Ubuntu 20.04 as
vulnerable to CVE-2021-4034. The verifier pipeline is now ready for
sweep across the rest of the corpus.

2026-05-23 15:26:51 -04:00

README.md

tools/verify-vm: turnkey Vagrant + Parallels verification scaffolding

2026-05-23 11:19:28 -04:00

setup.sh

tools/verify-vm: turnkey Vagrant + Parallels verification scaffolding

2026-05-23 11:19:28 -04:00

targets.yaml

tools/verify-vm: turnkey Vagrant + Parallels verification scaffolding

2026-05-23 11:19:28 -04:00

Vagrantfile

verify-vm: fix Vagrantfile for first real run

2026-05-23 14:59:10 -04:00

verify.sh

verify-vm: close the loop — first successful end-to-end VM verification

2026-05-23 15:26:51 -04:00

README.md

SKELETONKEY VM verification

Auto-provisions a Parallels Desktop VM with a known-vulnerable kernel, runs skeletonkey --explain <module> --active inside it, and emits a verification record. Closes the loop between "detect() compiles & passes unit tests" and "exploit() actually works on a real vulnerable kernel."

One-time setup

./tools/verify-vm/setup.sh

That installs (if missing): Vagrant via Homebrew, the vagrant-parallels plugin, and pre-downloads ~5 GB of base boxes (Ubuntu 18.04/20.04/22.04

Debian 11/12). Idempotent — re-run any time.

To skip boxes you don't need (save disk):

./tools/verify-vm/setup.sh ubuntu2004 debian11   # only those two

Verify a single module

./tools/verify-vm/verify.sh nf_tables

What that does:

Reads tools/verify-vm/targets.yaml: finds nf_tables → box generic/ubuntu2204 + kernel pin linux-image-5.15.0-43-generic.
vagrant up skk-nf_tables (provisions on first call, resumes on subsequent).
Installs the pinned vulnerable kernel via apt, reboots.
Mounts the local repo at /vagrant, runs make, then runs skeletonkey --explain nf_tables --active.
Parses the VERDICT: line, compares against expect_detect from targets.yaml, emits a JSON verification record on stdout.
Suspends the VM (vagrant suspend) — instant resume next run.

Lifecycle flags:

./tools/verify-vm/verify.sh nf_tables --keep      # leave VM running; ssh in to inspect
./tools/verify-vm/verify.sh nf_tables --destroy   # full teardown after run

List every target

./tools/verify-vm/verify.sh --list

Shows the (module, box, target kernel, expected verdict, notes) matrix for all 26 modules. Three are flagged manual: true because no public Vagrant box covers them:

vmwgfx — only reachable on VMware guests; needs a vSphere/Fusion VM not Parallels.
dirtydecrypt, fragnesia — only present in Linux 7.0+ which isn't shipping as a distro kernel yet.

For those, verification needs a hand-built or special-distro VM.

Verification records

verify.sh emits JSON on stdout after each run. Example:

{
  "module":        "nf_tables",
  "verified_at":   "2026-05-23T17:42:11Z",
  "host_kernel":   "5.15.0-43-generic",
  "host_distro":   "Ubuntu 22.04.5 LTS",
  "vm_box":        "generic/ubuntu2204",
  "expect_detect": "VULNERABLE",
  "actual_detect": "VULNERABLE",
  "status":        "match",
  "log":           "tools/verify-vm/logs/verify-nf_tables-20260523-174211.log"
}

status: match means detect() returned what we expected on a known- vulnerable kernel. Anything else (MISMATCH, status code != 0) means either:

The kernel pin didn't take (check host_kernel against kernel_version in targets.yaml).
The exploit's preconditions aren't met in the default Vagrant image (e.g. apparmor blocks unprivileged userns; need to adjust the Vagrantfile provisioner).
The detect() logic is wrong for this kernel/distro combo (a real bug — fix it).

Records are intended to feed a per-module verified_on[] table (next project step) so --list can show a ✓ verified <date> column.

How it routes module → box

Mapping lives in tools/verify-vm/targets.yaml. Each entry has:

box — which boxes/ template (e.g. ubuntu2204)
kernel_pkg — apt package name to install if the stock kernel is patched (omit / empty if stock is already vulnerable)
kernel_version — what uname -r should report after install
expect_detect — VULNERABLE | OK | PRECOND_FAIL
notes — short rationale; comments in the file have the full context

Adding a new module is one block in targets.yaml. The verifier picks it up automatically.

Files

tools/verify-vm/
├── README.md       this file
├── setup.sh        one-time bootstrap (Vagrant, plugin, box cache)
├── verify.sh       per-module verifier
├── Vagrantfile     parameterized VM config (driven by SKK_VM_* env vars)
├── targets.yaml    module → box mapping with rationale
└── logs/           per-verification stdout/stderr capture

Why Vagrant + Parallels

You already have Parallels Desktop. vagrant-parallels gives a scriptable per-VM config + a curated public box library + idempotent vagrant up/provision/reload/suspend lifecycle. The Vagrantfile is parameterized via env vars so a single file drives every target.

Alternative providers (Lima, Multipass) would also work; Vagrant was chosen for ergonomic continuity with the existing Parallels install.