DF-3133 — dirfs_node_chsize() destroys the guest page cache before the host

truncate() is known to succeed (and ignores absolute_path()==NULL)

What

dirfs_node_chsize (sys/vfs/dirfs/dirfs_subr.c:778-793) runs nvtruncbuf()/nvextendbuf() on the vnode first, and only then attempts the host-side truncate(tmp, nsize). If that truncate fails — deterministically EFAULT when dirfs_node_absolute_path() returned NULL (unlinked-but-open node with dn_parent already cleared by dirfs_nremove/nrmdir/nrename, or absolute path > MAXPATHLEN), or EPERM/ EACCES/ENOSPC from the host — the damage is already done and is never rolled back:

• nvtruncbuf destroys every buffer at/beyond the truncation point without flushing (B_INVAL|B_RELBUF|B_NOCACHE, sys/kern/vfs_vm.c:300-302) — including B_DELWRI buffers holding write(2)-acknowledged data → the acknowledged writes are silently lost and subsequent reads resurrect the OLD host data;
• the VM object is resized (nvnode_pager_setsize) to nsize while the host file is unchanged → mmap view desyncs (SIGBUS on data that read(2) still returns);
• chsize has no dn_flags & (IMMUTABLE|APPEND) guard (unlike chtimes :656-657) and the setattr size branch has no ownership check (dirfs_vnops.c:491-503 only checks MNT_RDONLY), so any guest user can inflict this on the shared cached view of any dirfs file whose host truncate then fails.

tmp (the dirfs_node_absolute_path() return, :778) is never NULL-checked — unlike the sibling ch* wrappers whose KKASSERT(tmp) family is DF-0855.

Reproduce

dirfs is vkernel-only, so proof is by deterministic harness transcription (DF-3054/DF-0806/DF-0807 precedent) — verbatim absolute_path + chsize control flow, nvtruncbuf/nvextendbuf stubbed to the documented vfs_vm.c semantics, real host files and real truncate()/pread so all errno outcomes are real.

ssh dfbsd-maxx        # unprivileged (uid 1001)
cd poc/DF-3133
./build.sh && ./run.sh   # expect rc=2: 9/9 BUG confirmations + FIXED variants

Expected (see run.log): * A) unlinked-but-open: chsize → EFAULT after the dirty acknowledged write was destroyed and the pager truncated; host data still alive through the open fd; guest re-read resurrects OLD data. * B) >MAXPATHLEN absolute path — tree really constructed on the host via fd-relative openat() (the dirfs fd-cache trick); same damage; the 4x240 boundary path truncates normally (sanity). * C) valid path, root-owned file: EPERM from the host after the guest buffers/pager for that file were destroyed; host file verified untouched. * FIXED variant (NULL check + host-truncate-first): ENAMETOOLONG / errno propagated with ZERO damage in every scenario.

3/3 runs byte-identical (run.log, run.2.log, run.3.log — same MD5).

Fix

fix.diff (also validated): NULL check → ENAMETOOLONG, host truncate() first, buffer/pager updates only after success. Applies cleanly (git apply --check RC=0 local tree + guest /usr/src), compile-neutral (fix_base_cc.log vs fix_patched_cc.log: identical first error — the pre-existing vkernel-env errno.h breakage documented in DF-3054). Live vkernel boot not available on this guest → boot validation not_testable (same as DF-3054).

DF-3133 — dirfs_node_chsize() is destructive-before-validate

Verdict

REPRODUCED (deterministic harness, 3/3 runs byte-identical) — dirfs_node_chsize (dirfs_subr.c:778-793) mutates the vnode's buffer cache and pager (nvtruncbuf/nvextendbuf) BEFORE the host truncate() is attempted, never checks dirfs_node_absolute_path() for NULL, and never rolls anything back when the host truncate fails. Demonstrated failure modes, each with the guest-side damage already committed:

1. unlinked-but-open (dn_parent cleared by dirfs_nremove vnops.c:914-916 / nrmdir :1128-1130 / nrename :1000-1002): absolute_path → NULL → truncate(NULL) → EFAULT. nvtruncbuf had already destroyed the B_DELWRI buffer holding a write(2)-acknowledged write (vfs_vm.c:300-302 — dirty buffers are destroyed, not flushed) and truncated the VM object. The host file's data is still fully alive through the still-open descriptor (POSIX unlink semantics hold on the host), and the guest's next read re-fetches the OLD data: the acknowledged write is silently REVERTED. The mmap view SIGBUSes on data read(2) still returns.
2. absolute path > MAXPATHLEN (>1024 bytes of components, constructed for real on the host through fd-relative openat() — exactly the mechanism dirfs's own passive fd cache uses, so such trees are fully constructible by an unprivileged user): same NULL → EFAULT → committed damage. The 4x240-byte boundary (count ≤ MAXPATHLEN) truncates normally — sanity.
3. host refuses the truncate (root-owned file, valid path): EPERM returned, but the guest's cached buffers/pager for that file were destroyed anyway. The setattr size branch (vnops :491-503) has no ownership check (only MNT_RDONLY) and chsize lacks the IMMUTABLE|APPEND guard chtimes has (:656-657), so any guest user can inflict this on the shared cached view of files they cannot modify.

Impact ceiling: guest (vkernel) data-integrity + availability — silent loss of acknowledged writes, resurrection of stale data, mmap/read desync, and denial of the cached contents of arbitrary dirfs files. dirfs is vkernel-only (sys/platform/vkernel64/conf/files:45-47), so this is a vkernel integrity/DoS issue, not a host-kernel crash.

The bug — line by line

:778  tmp = dirfs_node_absolute_path(dmp, dnp, &pathfree);   /* may be NULL */
:779  if (nsize < osize) {
:780      error = nvtruncbuf(vp, nsize, biosize, -1, 0);     /* DESTROYS buffers
                                                                + pager FIRST */
:781  } else {
:782      error = nvextendbuf(vp, osize, nsize, ...);        /* extends FIRST */
:785  }
:786  if (error == 0 && truncate(tmp, nsize) < 0)            /* host SECOND;
                                                                tmp may be NULL */
:787      error = errno;                                     /* damage stays */
:788  if (error == 0)
:789      dnp->dn_size = nsize;

nvtruncbuf_bp_trunc (sys/kern/vfs_vm.c:280-306) takes both the clean AND the dirty rb-tree; dirty buffers get bremfree + B_INVAL|B_RELBUF|B_NOCACHE + brelse — the data is dropped, never written. nvnode_pager_setsize (vfs_vm.c:165) then resizes the VM object. (The bawrite at vfs_vm.c:343 is only in the metasync callback, which matches negative-loffset metadata buffers only — vfs_vm.c:316.)

Distinction from known findings

• DF-0855 owns the KKASSERT(tmp) family in chtimes:660/chflags:698/ chmod:718/chown:736 (panic sites). chsize :778 has NO KKASSERT — its NULL flows into truncate(NULL) (EFAULT) after the destructive helpers ran. This finding is about the destructive ordering, which no known finding covers.
• DF-3057 is dirfs_write's bread()-error clobber (vnops:740-753) — different function, different mechanism.
• DF-0808 owns nrename's absolute_path_plus NULL → rename(NULL,...) (no damage to the page cache).
• DF-3054/DF-0855/DF-0856 own the findfd-family NULL derefs and the alloc_file leak. Untouched here.

Reproduction (harness; dirfs is vkernel-only — DF-0806/0807/3054 precedent)

A) chsize returned 14 (Bad address)
   BUG A1: truncate(NULL) -> EFAULT after damage already done
   BUG A2: acknowledged (dirty) write DESTROYED without flush
   BUG A3: pager/VM object truncated to 0 while host file unchanged
   BUG A4: guest re-read resurrects OLD data — acknowledged write REVERTED
   FIXED A: clean ENAMETOOLONG / zero damage, dirty buffer intact
B) BUG precondition: >MAXPATHLEN tree IS constructible via fd-relative
   openat() (dirfs does the same through the passive fd cache)
   BUG B1/B2: absolute_path NULL -> EFAULT after buffer+pager damage
   B-sanity: 4x240 boundary path truncates normally
   FIXED B: ENAMETOOLONG, zero damage
C) chsize returned 13 (Permission denied)
   BUG C1/C2: host refuses truncate, guest pager/buffers destroyed anyway
   host file verified untouched
   → exit code 2, 9/9 confirmations, 0 mismatches; 3/3 identical runs

Fix validation

• fix.diff (NULL check → ENAMETOOLONG; host truncate FIRST; buffer/pager updates only on success) — git apply --check RC=0 on the local sys/ tree AND on the guest /usr/src.
• Compile-neutral: patched vs unpatched dirfs_subr.c compiled in the vkernel64 ad-hoc env fail with IDENTICAL first errors (pre-existing errno.h include breakage, same as DF-3054/DF-0806 documented). (fix_base_cc.log vs fix_patched_cc.log.)
• Behavior: harness FIXED variants show zero damage in all scenarios.
• Live boot test: not_testable — dirfs is not compiled into the guest host kernel and no vkernel boot is available on this guest (same as DF-3054).

How to reproduce

ssh dfbsd-maxx   # unprivileged (uid 1001)
cd poc/DF-3133
./build.sh && ./run.sh     # expect: rc=2 "BUG CONFIRMED + FIX VALIDATED"

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.