DF-2626 — VERDICT (verify mode)

Status: REPRODUCED (impact: dos, confidence: certain). Fix authored and VALIDATED in-guest (fix_status: fixed).

1. Source analysis (all claims checked line-by-line)

• hammer2_vnops.c:926-985 — the read loop: while (uio->uio_resid > 0 && uio->uio_offset < size). Inside, the only break is on cluster_readx() failure (:971-974). n is min(lblksize-loff, uio_resid, size-offset) (:977-981) — always > 0 for a non-empty file at offset 0. The result of uiomovebp(bp, bp->b_data + loff, n, uio) at :983 is DISCARDED; there is no error re-check and no n==0 break. error at loop entry is whatever cluster_readx left (0 for a cached buffer).
• kern_subr.c:117-156 — uiomove(): on copyout() failure it executes if (error) break; at :148-149 BEFORE uio_resid -= cnt; uio_offset += cnt; at :152-153. A fault at the FIRST byte therefore leaves resid and offset completely unchanged and returns EFAULT. (The "uiomove advances resid before copyout" alternative reading in the claim is wrong — this ordering is exactly what makes byte-0 faults livelock the caller when the caller ignores the return.)
• Consequently: fault at byte 0 + discarded EFAULT => loop predicate is unchanged => infinite in-kernel loop. The thread holds the vnode lock SH (kern/vfs_vnops.c:751, vn_lock(vp, LK_SHARED) around VOP_READ) and ip->truncate_lock SH (hammer2_vnops.c:922, released only at :986, i.e. never). It never sleeps and never returns to user mode, so a pending SIGKILL (delivered only at user-mode boundary or PCATCH sleep) can never be acted on: UNKILLABLE, 100% of one CPU per read() call.
• Reachability: any unprivileged user, any readable hammer2 file. The guest's root filesystem is hammer2 (vbd0s1d on / (hammer2, local)). readlink() is an identical vector via hammer2_vop_readlink (:779-790) -> hammer2_read_file. Note the WRITE path already checks the error (:1144-1147) — the read loop was simply missed.

2. Empirical reproduction (stock kernel #0, INVARIANTS, 6 vCPU)

Trigger guarantee: destination page mmap'd PROT_NONE at a fixed address — copyout faults deterministically at byte 0.

(a) Single read() [run.log, mirrored on serial console serial_wedge1.log] pid 988 uid 1001 (unprivileged "maxx"): STAT R2, %CPU 100.0, wchan -, top: CPU2 99.85% df2626poc; whole-box CPU states 16.6% system = exactly 1/6 CPUs pinned in kernel mode. kill -9 returned 0 twice; the process was STILL ALIVE AND SPINNING after both (checked at +3 s and +7 s). No sleep, no panic — pure spin. This satisfies the "unkillable in-kernel infinite loop" claim verbatim.

(b) readlink() vector [readlink_stock.log, serial_readlink_stock.log] Single unprivileged readlink() of /home/maxx/df2626link (hammer2 symlink) into the PROT_NONE page: the monitoring ssh session died mid-script and ~60 s later ssh failed with "Connection timed out during banner exchange" while the serial console stayed silent (no panic). The wedge cascades because the spinner holds truncate_lock/vnode lock SH forever while hammer2 flush/buffer-cache reclaim paths need progress.

(c) Whole-box starvation [wedge2.log, serial_wedge2.log] Six readers on six DIFFERENT hammer2 files: the monitoring script printed only its header line to the serial console, then nothing — every CPU pinned by an unkillable spinner, interactive userspace starved, ssh dead (vm.sh status => down), serial console silent for 30+ s. Same-file readers (7 on /etc/rc) instead interleave in getblk (buffer-lock sleeps): CPU states 100% system, 0.0% idle but ssh limps — documented in wedge1.log; distinct files remove the only sleep point.

(d) Control (other filesystem) [wedge1.log] Identical PoC against a tmpfs file: immediate read returned -1 errno=14, kernel console prints tmpfs_read uiomove error 14 — tmpfs checks uiomove's return value and exits its loop. This isolates the defect to hammer2's read loop, not to the VM fault path.

3. Fix validation (fix.diff)

fix.diff (git-apply-able, -p1): - uiomovebp(bp, bp->b_data + loff, n, uio); + error = uiomovebp(bp, bp->b_data + loff, n, uio); bqrelse(bp); + if (error) + break;

Applied to the guest's /usr/src, kernel rebuilt (make -j6 nativekernel KERNCONF=X86_64_GENERIC && make installkernel, hammer2_vnops.c compiled clean under -Werror), rebooted into "DragonFly 6.5-DEVELOPMENT #1: Fri Aug 28 20:29:47 UTC 2026".

baseline (stock #0): livelock as in (a)-(c). baseline_reproduced=1 patched (#1): same PoC binary (md5 ed5f88f79641d7b5f1e53ec714524016) returns -1/EFAULT in 0.00 s, exit 0 [fix_run.log]; readlink variant same [fix_readlink.log]. patched_reproduced=0 regression on patched: 50/50 good reads of /etc/rc fine, 50/50 bad reads return EFAULT; the exact 6-distinct-file pattern that wedged the stock kernel leaves "spinners left: 0" and the box 98.9% idle [fix_regress.log].

POSIX-semantics note: on a mid-buffer fault the fix returns EFAULT after a partial copy (uio already advanced); this matches tmpfs behavior and FreeBSD/DragonFly conventions for read(2) with a faulting buffer.

4. Honest deviations / notes

• The evidence-pack seed suggested (void*)0x10000 as the bad address; that address can be mapped, so the PoC uses mmap(PROT_NONE, MAP_FIXED) to GUARANTEE fault-at-byte-0. A plain bad pointer works equally well when it faults (first-ever incident log serial_initial_wedge.log used an unmapped address and also wedged the box).
• DragonFly guest has no procstat(1) and no setsid(1); kernel-stack capture was unavailable — the R-state/100%-CPU/wchan -/unkillable evidence plus the source trace carry the proof.
• The in-guest build log was destroyed by the final snapshot reset before it could be fetched; fix_build.log preserves the verbatim poll excerpts (hammer2_vnops.o -Werror clean, module install, BUILD_INSTALL_OK, kernel timestamp) — flagged as excerpt.
• The first-ever run (serial_initial_wedge.log) wedged the box from a single reader via an unmapped (not PROT_NONE-mmap'd) destination — same root cause, before instrumentation existed.
• Guest left CLEAN: final vm.sh reset with-src; stock kernel #0; no spinners; ssh up (verified).

5. Impact classification

Local unprivileged user -> unkillable per-CPU kernel spin per read()/readlink() call; N distinct files = N CPUs; all CPUs = full system starvation (no panic, requires hard reset / power cycle of the VM or console intervention; even root cannot kill the offenders). This is a straightforward local DoS on the default root filesystem type — Medium severity as filed is appropriate (no memory corruption, no info leak, no privilege boundary crossing).