# VERDICT — DF-2533 (REPRODUCED: kernel panic + permanent lock leak)

## Bottom line

Both defensive early-return paths in `xa_close` are defective exactly as
claimed, and both defects were mechanically demonstrated by driving the REAL
`xa_close` (verbatim, sha256-gated, compiled into the guest kernel) into each
path with fabricated raced-destruction state:

1. **Path 1 — `si_drv1 == NULL` (xdisk.c:769-770): returns holding the
   exclusively-acquired `xdisk_lk` (leak).**
   Observed: `xa_close returned 6` (ENXIO) and
   `xdisk_lk lockstatus=2 after return (LK_EXCLUSIVE=2 => EXCLUSIVE LOCK LEAKED)`.
   A probe thread running the REAL `xa_open` on another CPU wedged forever on
   the leaked lock (`started=1 finished=0 => STUCK FOREVER`) — the leak
   deadlocks every later xdisk subsystem operation: `xdisk_open`,
   `xdisk_close`, `xdisk_ioctl` (XDISKIOCATTACH), `xa_open`, `xa_close`,
   `xaio_rcvdmsg` (every dmsg rx dispatch), `xa_terminate_check` callers.
   The harness released the lock afterwards only to keep the guest alive; a
   production caller has no owner to release it: the leak is permanent.

2. **Path 2 — `sc->terminating` (xdisk.c:771-773): releases `sc->lk`, a lock
   that was NEVER acquired, while still holding `xdisk_lk`.**
   Observed: unconditional kernel panic
   `panic: lockmgr: LK_RELEASE: no lock held`
   backtrace `lockmgr_release() <- xa_close() at xa_close+0x183` —
   kern_lock.c:768 panics on any release of a lock with no holders; this is
   NOT INVARIANTS-gated, so production kernels panic too. Pre-call state
   printed: `sc->lk.lk_count=0x0` (lockinit leaves count 0). Had a kernel not
   panicked, `xdisk_lk` would additionally be leaked on this path as well.

The correct pattern exists 60 lines above in `xa_open` (:703-715): both of
its defensive paths `lockmgr(&xdisk_lk, LK_RELEASE)` before returning.

## Production reachability (honest quantification)

- The device ops carry `D_TRACKCLOSE` (xdisk.c:188), so devfs dispatches
  `d_close` for EVERY close of a `/dev/xa%d` node, not just the last
  (sys/vfs/devfs/devfs_vnops.c:1104/1170). Two processes holding the node
  open: peer drops the span AND the first closer drives `opencnt` to 0 →
  `xa_terminate_check` frees the softc and NULLs `si_drv1` (:665-680) under
  `xdisk_lk` → the second closer enters `xa_close`, acquires `xdisk_lk`,
  reads `si_drv1 == NULL` and takes the leak path. A variant: `xa_open`'s
  BLK_OPEN error unwind (:749-753) runs `xa_terminate_check` while devfs
  still owes the error-path `d_close`.
- The `terminating` branch requires observing `si_drv1 != NULL` together
  with `sc->terminating == 1`; in the current code both transitions happen
  under `xdisk_lk` inside `xa_terminate_check`, so this branch is defensive
  (dead today) — but it is a booby trap: any future reordering (e.g. moving
  the `terminating = 1` store, or splitting the lock) turns it into the
  panic above. The panic was verified mechanically with fabricated state.
- Threat model (per team directive): xdisk devices are created by root via
  dmsg attach, but the resulting `/dev/xa%d` nodes are ordinary block
  devices; ANY holder of an open node can trigger `xa_close` at the moment
  the raced destruction state arises. Impact ceiling: permanent subsystem
  wedge of all xd* devices plus the dmsg rx machinery (local DoS), and — on
  the terminating path — an unconditional kernel panic. No memory-corruption
  primitive: no uid=0 chain exists for this bug class; the escalation
  ceiling is denial of service.

## Exploit chain

Not memory corruption. Chain is: (unprivileged holder of an xa node)
close(2) concurrent with span-loss teardown → leaked exclusive `xdisk_lk` →
every subsequent xdisk/dmsg operation sleeps forever (`xaopen`/`xawait`
stuck threads pile up) → subsystem-wide local DoS; or the terminating
variant → instant node panic.

## Fix validation (fixed)

`fix.diff` mirrors the `xa_open` pattern: both defensive paths release
`xdisk_lk`; the terminating branch no longer touches `sc->lk`. Applied in
guest /usr/src (both DF-2533+DF-2534 diffs, combined tree sha256
`15d189799d499d96ee6bbb5796ef3b3c5e316fce06d15507a47776119ae43385`),
kernel rebuilt (#3 Mon Oct 19 21:13:06) and the EXACT same triggers re-run:

- baseline: lockstatus=2 after `xa_close` return, probe thread stuck;
  patched: lockstatus=0, probe completes (run.patched.log)
- baseline: `panic: lockmgr: LK_RELEASE: no lock held`;
  patched: clean ENXIO return, no panic, `sc->lk.lk_count=0x0` untouched

## PoC notes

- The harness kernels were built from the verbatim guest source (sha256
  gate in build.sh, hash recorded in env.txt/sha256_gate.log); only the
  external registration calls were interposed via pre-include `#define`
  renames — `xa_close`/`xa_open` machine code is the shipping code.
- The probe thread calls the real `xa_open`, not a stubbed lock take.
- Harness iterations: first race-hammer version starved a CPU (LWKT
  cooperative scheduler) and wedged the guest mid-run; fixed with periodic
  1-tick `tsleep` in the hammer loops (harness-only artifact, unrelated to
  the finding).

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.