# DF-3162 VERDICT — reproduced (security revocation mechanism fail-open for FIFOs)

## Reproduced?  Yes.
On the stock INVARIANTS guest kernel #0 (2026-09-07), as unprivileged
user uid=1001 owning the fifo: `revoke(2)` returned 0 and the
previously-opened descriptors **still passed data** afterwards
(run.log).  A working revoke must invalidate the descriptors (writes
fail EPIPE / reads EOF), as it does for regular files on this system.

## Why (line-level)
- sys/kern/vfs_syscalls.c:4746-4747 — non-device vnodes go to
  `vrevoke(vp, cred)`.
- sys/kern/vfs_subr.c:1450-1452 — `vrevoke` calls
  `fdrevoke(vp, DTYPE_VNODE, cred)` for every non-VCHR vnode.
- sys/kern/vfs_default.c:1172-1175 — `vop_stdopen` tags fifo fps
  `fp->f_type = DTYPE_FIFO`.
- sys/kern/kern_descrip.c:1999 — the match requires
  `info->type == fp->f_type`; `DTYPE_VNODE(1) != DTYPE_FIFO(4)`
  (sys/sys/file.h:125,128).  Nothing matches; `info.found` stays 0;
  fdrevoke returns 0 having done nothing.

## Impact
`revoke(2)` is an administrative/defensive mechanism ("cut off all
access through this file now").  For FIFOs it fails *silently*: the
caller believes revocation happened; every reader/writer keeps its
access until natural close.  An unprivileged user can verify this on
their own fifos; exploiting it requires a scenario where someone relies
on revoke for isolation (e.g. revoking a fifo used as a service channel
after a compromise).  Severity Low (mechanism failure, no direct memory
safety impact).

## Fix validation
`fix.diff` (this directory): `vrevoke` passes `DTYPE_FIFO` for VFIFO
vnodes.  Applied on the rebuilt guest kernel (same build as DF-3161's
fix validation), the PoC output changes from "fds still functional" to
descriptors being revoked (see fix_run.log) — the previously-opened
descriptors no longer pass data after revoke(2).

## Chain summary
Unpriv user -> revoke(own fifo) returns success but is a no-op.
No escalation path; correctness/defense-in-depth defect.

## 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.