DF-3116 VERDICT — stale de_fndoffset TOCTOU in msdosfs_rename → createde overwrite

Status: not_reproduced (the dirent-theft interleaving itself); the code defect is proven by dataflow; the race family demonstrably fires (kernel logged rename races) and its adjacent consequence (system wedge) is reproduced and filed as DF-3117.

The defect (code-certain)

1. sys/kern/vfs_default.c:1054 — vop_compat_nrename runs vop_old_lookup(tdvp, &tvp, &tcnp) with cn_nameiop = NAMEI_RENAME; for a non-existent target msdosfs_lookup returns EJUSTRETURN with tdvp locked and dp->de_fndoffset = first-fit free slot S (msdosfs_lookup.c:367-400).
2. msdosfs_vnops.c:1009-1010 — to_diroffset = dp->de_fndoffset saved while tdvp is locked.
3. msdosfs_vnops.c:1045 (Window A: doingdirectory && newparent) or msdosfs_vnops.c:1127 (Window B: newparent == 0) — tdvp unlocked; a concurrent create() in the same directory deterministically picks the same first-fit slot S (vop_compat_ncreate, vfs_default.c:349 → msdosfs_lookup CREATE → msdosfs_create → createde writes X's dirent at S).
4. msdosfs_vnops.c:1186-1187 — after relocking, dp->de_fndoffset = to_diroffset restores the stale slot; relookup's fresh value is discarded.
5. msdosfs_lookup.c:644-646 — createde() does ndep = bptoep(pmp, bp, ddep->de_fndoffset); DE_EXTERNALIZE(ndep, dep); with zero revalidation → X's live dirent is overwritten by the renamed entry. Victim's data cluster orphaned; victim denode stays keyed at the stolen slot (cross-file metadata confusion for as long as it is cached).

FreeBSD identified this same stale-offset family in its pre-2019 msdosfs_rename and resolved it by rewriting the function to re-derive the slot after every relock rather than restoring saved values.

Verification attempts (10 runs on the QEMU guest)

Detection was NOT the limiting factor after run.4: every created file is verified via readdir() (dirents read through the buffer cache, no namecache) and again via its rotation unlink 200 creates later (ENOENT ⇒ theft). Across all runs zero rotation-unlink failures occurred — the create-inside-the-window interleaving never landed.

Why it never landed (measured): Window B's unlock→relock gap is ~100 ns of instructions on the same CPU; wakeup latency of the blocked creator (~5-50 µs) loses the handoff every time. Window A was widened to the whole doscheckpath walk by placing the target parent at the bottom of a 100-deep ".." chain (each hop = bread + deget incl. a pcbmap(0xffff) chain walk + vput), giving ~200 µs windows at ~4k renames/s — still no landing. The kernel's own kern_rename: retry due to race on: "D68634" -> "D68634" (12,0) (sys/kern/vfs_syscalls.c:4323, seen on the console) proves concurrent modification during rename occurs, but the exact createde-runs-inside-the-window ordering did not happen in ~1e6 opportunities on this 6-vCPU KVM guest.

Classification: real code defect (blind trust of cached slot state across an explicit lock drop — CWE-367), exploitability demonstrated only down to "window provably opens under unprivileged racing"; the corruption itself not observed. Downgraded to confidence=likely, severity Medium. The verified DoS consequence of racing this same path is filed separately as DF-3117 (reproduced).

Fix validation

fix.diff adds a revalidation pass to createde() (all slots in [fndoffset − fndcnt·32, fndoffset] must still read SLOT_EMPTY or SLOT_DELETED, else EEXIST). Compile-verified: applied to the guest's /usr/src copy, make in sys/vfs/msdosfs built msdos.ko clean with -Werror; source restored afterward. Runtime A/B not meaningful (baseline theft not reproduced); fix_status=not_testable.

Artifacts

• trigger.c — racer (renamer/bouncer/creator/sweep), final
• run.sh — full run: fresh FAT32 image, baseline + race + sweeps + fsck
• wedge.sh — attribution-clean single-shot wedge probe (see DF-3117)
• run.3.log, run.5.log, run.9.log, run.10.wedge.log — runs
• build.log, fix.diff

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.