# VERDICT — DF-2705

**status: untested** (Phase V deliberately skipped: Low severity; reproduction
requires reconfiguring the shared guest's boot tunables + vquota limit setup,
disproportionate for an accounting-bypass finding).

## Complete logic chain (all lines verified this pass)

1. Feature gate: `int vfs_quota_enabled = 0;` with `TUNABLE_INT` and `SYSCTL_INT
   (..., CTLFLAG_RD, ...)` — sys/kern/vfs_quota.c:111-113. Boot-time only,
   default off. Everything below is conditional on the admin enabling it.
2. Charging skip: sys/kern/vfs_vopops.c:476-478 — `do_accounting` only when
   `va.va_nlink > 0`; :495-497 charge gated on `do_accounting`.
3. Check still runs: :489 `vq_write_ok(mp, va.va_uid, va.va_gid, delta)` —
   implementation sys/kern/vfs_quota.c:411-461 compares `space + delta` against
   per-uid/gid/mount limits, where `space` is the charged usage
   (`vfs_stdaccount` :150-171 is the only writer, called via VFS_ACCOUNT).
4. Removal refund: sys/kern/vfs_vopops.c:1665-1668 — on last-link remove the full
   `va.va_size` is subtracted from usage.
5. Bypass: unlink an open fd (usage drops to ~0, nlink becomes 0) → subsequent
   writes through the fd are checked against usage that never grows
   (their own growth is never charged) and each individual write's delta only has
   to fit the limit once → unbounded growth past any per-uid/mount limit.
6. TOCTOU (secondary): concurrent writers on separate files both compute delta
   against the same stale `space` inside `vq_write_ok`; the check-then-charge
   gap spans the entire write, so N concurrent writers can overshoot the limit by
   (N-1)×limit.
7. Cross-refs surveyed for completeness: ftruncate/chown *are* accounted at the
   syscall layer (sys/kern/vfs_syscalls.c:3560-3561, 4048, 4124;
   sys/kern/vfs_vnops.c:326) — the nlink==0 skip in vop_write is the gap.

## Honest classification

- Certain as a code-level logic flaw; exploitable only where an admin enabled
  `vfs.quota_enabled=1` at boot.
- Impact ceiling: quota enforcement bypass → disk exhaustion on the quota'd
  mount (multi-user DoS); no memory-safety consequence (VFS_ACCOUNT with this
  delta feeds int64 counters only).
- Cross-file note for the orchestrator (belongs to the vfs_quota.c row, not this
  finding): `vfs_stdaccount` calls `unode_insert`/`gnode_insert`
  (sys/kern/vfs_quota.c:153-165) which do `kmalloc(..., M_ZERO|M_WAITOK)` while
  `mp->mnt_acct.ac_spin` is held — blocking allocation under a spinlock; same
  pattern in cmd_set_usage_all/cmd_set_limit_uid/gid (:236-306). Recommend a
  separate finding against sys/kern/vfs_quota.c.