# DF-3171 — VERDICT

**Status: not_reproduced (for the hypothesized trigger). The code hazard is
real but no reachable trigger was demonstrable; see the honesty record
below. Confidence: speculative. Impact: none demonstrated.**

## What was hypothesized

`mfsclose()` (mfs_vfsops.c:136-147) clears `mfs_active` unconditionally,
taking the I/O server down on ANY device close. devfs calls `d_close` on
VRECLAIMED vnodes regardless of the remaining open count
(devfs_vnops.c:1169-1171), so a non-final close (vnode reclaim while the
mount still holds the device) would kill the server under a live mount →
`destroy_dev` (async, devfs_core.c:754-763) + `kfree(mfsp)`
(mfs_vfsops.c:494-498) → still-mounted filesystem doing I/O through a
freed mfsnode (UAF).

## What actually happened (honesty record)

1. First stock attempt (~15:56): `exec 8<>/mnt/d2/mfs853` + `umount -f`.
   The box panicked with `Bad tailq NEXT(...->tqh_last) != NULL` from
   mfsstrategy — **initially filed as this finding's reproduction. That
   attribution was wrong**: the `8<>` (O_RDWR) open of a mounted-RW D_DISK
   device fails EBUSY in devfs_specopen (devfs_vnops.c:1006-1020), so no fd
   existed and no d_close ever fired. The panic was DF-3170's
   producer/consumer race, which the concurrently-running writers were
   exercising (full reanalysis in findings/poc/DF-3170/run.2.log — the
   panic evidence has been reattributed to DF-3170).
2. Second stock attempt (read-only open, fd held by a short-lived `sh -c`):
   the fd closed when the shell exited before umount — vclean had no
   opencount to force-close. Server survived.
3. Third stock attempt (read-only fd held by a `sleep 90` holder process
   across `umount -f /mnt/d2`): umount succeeded, **server survived, mount
   healthy, I/O fine** — because devfs device opens migrate to the device's
   PRIMARY vnode (devfs_specopen's orig_vp handling,
   devfs_vnops.c:956-1000 — "the returned ... might not be using the vp we
   supplied"), leaving the second-devfs vnode with zero open count; its
   reclaim fires no VOP_CLOSE, and the primary vnode (in the main /dev
   devfs) is never reclaimed while the system runs.

## Why this is still filed (speculative, Low)

The hazard is one miscount away: devfs_vnops.c:1148 and :1102 compute the
close gate with `count_dev(dev)` and are annotated **"XXX NOT SMP SAFE"**
in-tree. A miscount that yields a false `opencount == 1` on some close
while the mount holds another reference makes `mfsclose` fire early with
exactly the consequences hypothesized (server exit under a live mount,
destroy_dev + kfree of the serving mfsnode, bios on freed memory). The
in-tree comment at mfs_vfsops.c:120-121 ("We allow the underlying MFS block
device to be opened and read") makes stray opens an expected condition.
This reviewer could not win that race on demand in the time budget; no
reachable deterministic trigger exists via the devfs#2 construction.

## Fix (defense-in-depth, validated harmless)

`fix.diff`: `mfsclose()` ignores closes while `dev->si_mountpoint != NULL`
(ffs_unmount clears it before the real final close, ffs_vfsops.c:851-855).
Validated on a patched in-guest kernel (#1 Mon Sep 7 16:11:15 2026 and
rebuilt #2 16:51:08):
- mount / I/O / **normal unmount lifecycle fully intact** (umount rc=0,
  mount gone, server exited via EMOUNTEXIT, /dev/mfsN removed);
- read-only-fd + forced devfs umount construction: server survives, mount
  continues serving I/O;
- 11+ minutes of DF-3170 stress (plus ENOSPC churn) across multiple
  concurrent MFS mounts: no regression.

Since the bug itself never manifested, fix validation is recorded as
`inconclusive` (guard proven safe and lifecycle-preserving; bad behavior
absent on both stock and patched).

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