DF-3056 — evidence pack

Finding: dirfs_nrename never updates dn_parent on cross-directory rename — getattr/setattr/unlink act on the WRONG host file (old-path occupant) while fd I/O hits the original inode

Verdict: REPRODUCED (deterministic harness, real syscalls on a real tree). Impact: wrong-file metadata/content modification across users after cross-directory rename (split-brain fd-vs-path).

Reproduce

./build.sh
./run.sh     # expect BUG CONFIRMED + FIX VALIDATED; rc=2

See VERDICT.md for the full narrative; manifest.json / verdict.json for machine-readable results.

DF-3056 — dirfs_nrename never updates dn_parent on cross-directory rename: all subsequent path-based ops act on the WRONG host file

Verdict

REPRODUCED (deterministic harness with REAL syscalls on a real directory tree, identical over 3 runs) — after a cross-directory rename, dirfs_nrename updates only the node NAME:

:984  if (error == 0) {
:985      vp = fncp->nc_vp;              /* file being renamed */
:986      dnp = VP_TO_NODE(vp);
:987      dirfs_node_setname(dnp, tncp->nc_name, tncp->nc_nlen);   /* name only */
           /* no dn_parent update for fdnp != tdnp */

Every host path dirfs builds later walks dn_parent: dirfs_findfd (subr.c:470-481) and dirfs_node_absolute_path[_plus] (subr.c:412-425). With a stale parent the constructed path points into the OLD directory, so:

• dirfs_getattr (:389-393) stats whatever file NOW occupies the old path;
• the whole setattr family — chflags :477, chsize :495 (truncate), chown :521, chmod :545, chtimes :563 — via dirfs_node_absolute_path -> lchmod/lchown/lchflags/lutimes/truncate, operates on the old-path occupant;
• dirfs_nremove (:907-909) unlinkat's through dirfs_findfd — same stale path;
• fd-based I/O (dirfs_strategy pwrite/pread on dn_fd) keeps hitting the ORIGINAL inode → permanent split-brain (stat shows one file, read/write another);
• the passive-fd-list key (dnp->dn_parent,dn_name) used by dirfs_nresolve (:172-174) no longer matches, so the same host file can gain a second dirfs node.

Security consequence: the generic VFS layer checks permissions against the VNODE's cached attributes (the file the user owns), while the host syscall applies to the occupant of the old path and executes with the vkernel process's uid. An unprivileged vkernel user can rename their own file out of a shared directory, let another user's file take the old path, and then chmod/chown/utimes/chflags/truncate/unlink THAT file (integrity break across users; truncate destroys content). This is the DF-2979 "operating on the wrong file" class.

Reproduction (decision-logic transcription + real file ops)

The harness maintains the dirfs node graph exactly as dirfs builds it (root(fd) -> dirA -> f, root -> dirB), performs the host rename the way dirfs_nrename does (rename(fpath, tpath) with paths built by the transcribed dirfs_node_absolute_path), applies the exact post-rename node update (setname only), re-creates a 0600 "victim" at the old path, then transcribes dirfs_node_chmod (lchmod on the path built from the node graph):

nrename: rename("/tmp/.../dirA/f", "/tmp/.../dirB/f")
post-rename node: name="f" parent="dirA"   (NOT updated)
victim created at OLD path /tmp/.../dirA/f (mode 0600)
user chmod 0777 on their moved file (vnode == dirB/f):
      lchmod("/tmp/.../dirA/f", 0777)   <-- STALE PATH
      stat(dirA/f) [the VICTIM]:  mode=0777  *** VICTIM MODIFIED (wrong-file op) ***
      stat(dirB/f) [the TARGET]:  mode=0644  (untouched — split-brain confirmed)
      getattr via stale node returns mode=0777 -> ls -l shows the VICTIM's attrs for dirB/f
FIXED (parent updated):
      lchmod("/tmp/.../dirB/f", 0644) -> correct file modified; victim left alone

Deterministic over 3 runs (run.log, run.2.log, run.3.log).

Fix validation

fix.diff moves dn_parent (with refcount transfer) when fdnp != tdnp: git apply --check RC=0 on the local tree and guest /usr/src; compile-neutral (identical first compiler error patched vs unpatched); harness FIXED variant proves the correct file is targeted. Live boot: not_testable (dirfs vkernel-only).