DF-0002 — PoC

sys_fhopen() at sys/kern/vfs_syscalls.c:4933-4938 has a missing error = EINVAL before goto bad_drop when a VREG vnode has v_object == NULL after VOP_OPEN. The function returns 0 (success) while the reserved fd slot is freed and sysmsg_result is never written, so the caller sees "fd 0" (its own stdin) — no real descriptor allocated.

Info-severity correctness bug. fhopen is gated by SYSCAP_RESTRICTEDROOT (root-only) and the trigger requires an FS-invariant violation (a VREG vnode without a VM object after VOP_OPEN), which no in-tree filesystem produces. There is no security impact; reported for correctness/hardening.

Files

Build

./build.sh    # builds fhopen_spur + df0002_trigger.ko (guest, root, /usr/src present)

Run

./run.sh      # kldload df0002_trigger.ko && ./fhopen_spur

Expected output

Bug present (unpatched #0):

[*] v_object nullified on vnode for fd 3 (/tmp/df0002_tmpfs/file)
fhopen returned 0 (success)
BUG: fd 0 is stdin, no real descriptor was allocated

Fixed (single-fix #1):

[*] v_object nullified on vnode for fd 3 (/tmp/df0002_tmpfs/file)
fhopen failed as expected: Invalid argument (errno=22)

Normal usage (no KLD, normal FS) is unaffected on either kernel: ./fhopen_spur on a UFS file returns fhopen returned 3 (success) — a real descriptor.

Preconditions (realistic-threat model)

The KLD is root-only (kldload) and is just a tool to demonstrate the buggy code path fires; it is not part of any escalation chain. The bug itself is also gated by SYSCAP_RESTRICTEDROOT, so there is no privilege boundary being crossed. The realistic in-tree trigger is the FS-invariant violation alone (e.g. a buggy/out-of-tree/fuse filesystem) — without the KLD, the bug requires that violation to manifest.

DF-0002 — REPRODUCED + FIX VALIDATED

Verdict: REPRODUCED (logic/correctness bug, root-only) — and FIX VALIDATED (single-fix kernel boots, PoC now returns EINVAL instead of spurious success).

Mechanism

sys_fhopen at sys/kern/vfs_syscalls.c:4814 opens a vnode located via a file handle. After VOP_OPEN succeeds, the defensive check at lines 4933–4938 fires when the vnode is a regular file (VREG) that unexpectedly has no VM object (vp->v_object == NULL):

4933:   if (vp->v_type == VREG && vp->v_object == NULL) {
4934:       kprintf("fhopen: regular file did not "
4935:           "have VM object: %p\n",
4936:           vp);
4937:       goto bad_drop;            /* <-- error stays 0 from VOP_OPEN */
4938:   }

The goto bad_drop skips the only success-path assignment to sysmsg->sysmsg_result at line 4981. The bad_drop label (4986–4988) clears the reserved fd slot via fsetfd(fdp, NULL, indx) and fdrop()s fp, then falls into bad: (vput(vp)) → done: (mount_drop(mp)) → done2: return (error);. Because error is still 0 from the successful VOP_OPEN, the syscall returns 0 (success), and because sysmsg->sysmsg_result was never written, it retains the syscall-entry default of 0 — i.e. the caller's stdin (fd 0).

The caller therefore sees fhopen() "succeed" with fd 0, but no descriptor was actually allocated for the fhopen result. The reserved slot was freed, so the caller is left operating on its own stdin as if it were the requested file.

Why this is reachable only via an FS-invariant violation

v_object is initialized by vinitvmio() during vnode creation in every in-tree filesystem that supports fhopen (UFS, HAMMER, HAMMER2, msdosfs, cd9660, udf, ext2, tmpfs, …). After VOP_OPEN, v_object is always non-NULL for VREG vnodes. The buggy branch can therefore fire only on an out-of-tree filesystem that violates the VREG-has-VM-object invariant.

Demonstration (the bug DOES fire when the invariant is violated)

We mount a tmpfs, create a regular file, get its handle, and then ask a small KLD (df0002_trigger.ko) to null the vnode's v_object — recreating the invariant violation. Then we call fhopen(2) on the handle. tmpfs_open() does NOT re-create v_object (unlike ufs_open), so vp->v_object stays NULL when the defensive check at vfs_syscalls.c:4933 fires.

The KLD is root-only (kldload) and the bug is itself gated by SYSCAP_RESTRICTEDROOT (sys/kern/vfs_syscalls.c:4832). There is no privilege boundary being crossed — root can already open any descriptor — so this is reported as a correctness/hardening bug, Info severity, no security impact. The KLD is just a tool to demonstrate the buggy code path fires; it is not part of any escalation chain.

Unpatched baseline (#0) — single run:

$ ./fhopen_spur
[*] v_object nullified on vnode for fd 3 (/tmp/df0002_tmpfs/file)
fhopen returned 0 (success)
BUG: fd 0 is stdin, no real descriptor was allocated

dmesg:

DF-0002: corrupted vnode 0xfffff80118539080 (cleared v_object, was 0xfffff8008fad4040, type=VREG)
fhopen: regular file did not have VM object: 0xfffff80118539080     <-- the buggy kprintf at vfs_syscalls.c:4934
                                                                    <-- BUT no error is set; sysmsg_result retains the syscall-entry default of 0

Normal usage (no corruption, no KLD) is unaffected: ./fhopen_spur on a normal UFS file returns fhopen returned 3 (success) — a real descriptor, no bug.

Impact

None, security-wise. fhopen is root-only (SYSCAP_RESTRICTEDROOT), and the trigger requires an FS-invariant violation. A maintainer-facing concern only: an FS invariant violation should not present itself to userspace as a silent success returning the caller's stdin. Reported as Info for correctness.

Fix

fix.diff adds a single line — error = EINVAL; — before the goto bad_drop at vfs_syscalls.c:4937. This matches the finding markdown's ## Recommended fix proposal exactly (no divergence). The patch is git apply-able; it builds clean with make -j6 nativekernel KERNCONF=X86_64_GENERIC (rc=0, no errors).

Fix validation (Phase 8)

Built the single-fix kernel from the with-src baseline by applying ONLY fix.diff:

Before/after contrast (same PoC, same KLD, same trigger condition):

BEFORE (unpatched #0):
  fhopen returned 0 (success)
  BUG: fd 0 is stdin, no real descriptor was allocated
  dmesg: fhopen: regular file did not have VM object: 0xfffff80118539080

AFTER  (single-fix #1, sha256 7e62d83b…ebc4fa):
  fhopen failed as expected: Invalid argument (errno=22)
  dmesg: fhopen: regular file did not have VM object: 0xfffff80117251e80
         (kprintf still fires — the path is hit — but the syscall now returns
          EINVAL instead of spurious success.)

The kprintf at line 4934 still fires on the patched kernel (the defensive path is still reached); the only change is that the syscall now correctly returns EINVAL instead of leaking error == 0 to the caller.

Final guest state: reset to with-src (unpatched #0) so the next runner starts clean.