DF-3170 — VERDICT

Status: reproduced (panic). Impact: panic (kernel memory corruption primitive: cross-CPU corruption of an in-kernel TAILQ). Confidence: certain. Two independent stock-kernel manifestations: consumer-side "Bad link elm" from mfs_start (~3 min of stress) and producer-side "Bad tailq NEXT" from mfsstrategy (<90 s of stress) — see run.log, run.2.log, panic.txt, panic_run2.txt.

Guest

DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 (X86_64_GENERIC, INVARIANTS), QEMU/KVM, 6 vCPUs (hw.ncpu: 6), stock snapshot. Booted fresh via vm.sh reset with-src before the run.

How it was reproduced

1. root: mount_mfs -s 32768 swap /mnt/mfs → server pid 899 parked in mfsidl (the mfs_start loop), device /dev/mfs899, mount live.
2. unprivileged user maxx: 6 × /tmp/mfsrace /mnt/mfs 2 — six processes each hammering 2 files with 512-byte O_SYNC pwrite/pread loops.
3. Within ~3 minutes the guest panicked:

panic: Bad link elm 0xfffff8004f593d48 prev->next != elm
cpuid = 5
Trace beginning at frame 0xfffff80117f12668
mfs_start() at mfs_start+0x499 0xffffffff80913849
mfs_start() at mfs_start+0x499 0xffffffff80913849
vfs_start() at vfs_start+0x3b 0xffffffff8070d55b
sys_mount() at sys_mount+0x52f 0xffffffff80700ccf
syscall2() at syscall2+0x11e 0xffffffff80bd6a0e
Debugger("panic")

(panic.txt, boot serial log.) ssh died; vm.sh status → down.

Why this proves the root cause

• The panicking frame is mfs_start — the consumer of mfsp->bio_queue — inside bioq_takefirst/bioq_remove (sys/sys/buf2.h:148-175), hitting TAILQ_REMOVE's INVARIANTS check prev->next != elm (sys/sys/queue.h:505-519 family).
• The only writers of that TAILQ are bioq_insert_tail from mfsstrategy (mfs_vfsops.c:187) and the dequeue in mfs_start (mfs_vfsops.c:455). The producer runs under the BGL (mfs_ops has no D_MPSAFE; kern/kern_device.c:121,384-388) while the consumer deliberately does not (MNTK_ST_MPSAFE set at mfs_vfsops.c:401 → VFS_MPLOCK_FLAG no-ops in vfs_start, sys/sys/mount.h:408-417). No other lock exists. Therefore the corrupted linkage can only come from a producer racing the consumer across CPUs — exactly the interleaving predicted.
• cpuid=5 vs the server thread: 6-way SMP stress; every writer is unprivileged.

Exploit-chain assessment (why impact is filed as panic, not uid0)

On the INVARIANTS validation kernel every queue inconsistency traps immediately, so the observed result is a panic. On a production kernel the same interleavings give:

1. Lost bio — dropped TAILQ_INSERT update: the bio never completes; the issuing thread blocks uninterruptibly in biowait forever (local DoS, very reliable to cause, not steerable).
2. Stale tqh_last pointer store — after a lost-update removal, bio_queue.tqh_last can point at the bio_act.tqe_next field of a bio that has been biodoned and whose struct buf returned to the buffer cache. The next bioq_insert_tail then executes *(head)->tqh_last = elm, writing a kernel heap pointer (address of the new bio's buf — not attacker-chosen) into recycled kernel memory.

Pushing (2) to uid=0 requires all of: winning the few-instruction race on demand; the recycled victim struct buf being reused as an object whose corruption at bio_act's fixed offset yields a privilege-relevant primitive; and the value written (a buf address) being useful at that slot. Buffer-cache bufs are recycled kernel-internally (bufdaemon) into the same struct buf type — the stray store lands inside another buffer descriptor, corrupting buffer linkage rather than credentials; there is no allocator path that hands that slab slot to a ucred/proc/vtable object while the dangling tqh_last still references it, and the write value is never controlled. Documented blocker — no credible uid0 chain; the deliverable stands at reliable unprivileged kernel panic (+ latent corruption on non-INVARIANTS builds).

Negative space (checked and killed during pass 2)

• copyinstr(args.fspec,...) unchecked + size used in bzero(f_mntfromname+size, MNAMELEN-size) (mfs_vfsops.c:376-380): NOT a bug on pc64 — std_copyinstr stores *lencopied on ALL return paths, including the fault path (sys/platform/pc64/x86_64/support.s:705-715), and the stored value is always ≤ MNAMELEN-1.
• vget(devvp) overwriting the ENOENT guard when devvp == NULL (mfs_vfsops.c:350-354): unreachable — nlookup with flags 0 returns ENOENT for negative-cache entries (kern/vfs_nlookup.c:891,905), so the error == 0 branch always has a non-NULL nc_vp. Hardening wart only.
• bp->b_bcount = mfsp->mfs_size - boff truncation (mfs_vfsops.c:178): clip only executes when the remainder is smaller than the request, and requests are bounded by MAXPHYS/MAXBSIZE — no int truncation possible.
• devvp double-vrele on ffs_mountfs failure: killed — ffs_mountfs never vreles devvp on its error paths (ffs_vfsops.c:774-787), so mfs_vfsops.c:406 is the correct single drop.
• crafted fs->fs_size > mfs_size: no OOB — every access goes through mfsstrategy clip/EINVAL (mfs_vfsops.c:163-179) and mfs_doio's copyin/copyout, both fault-bounded.
• MNT_UPDATE path / EMOUNTEXIT plumbing (vfs_vfsops.c:115-116): correct; mfs_start returns only after dounmount() completed.

Fix validation

See fix_build.log / fix_run.log and the fix_* fields in verdict.json. Combined single-fix kernel (this fix + DF-3171's guard, which touches the same function) built in-guest with make nativekernel; the exact PoC stress and the DF-3171 kill sequence were re-run on it: no panic, mount I/O continues, unmount clean. Baseline (stock kernel) panicked in both runs.

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.