{
 "finding_id": "DF-3019",
 "status": "not_reproduced",
 "reproduced": 0,
 "impact": "none",
 "confidence": "likely",
 "verdict": "Reproduced the precondition exactly: kern.securelevel raised to 2, then 20 open(/dev/vn, O_WRONLY) calls - all return EPERM from the D_DISK+FWRITE check (devfs_vnops.c:1006-1010) and each creates a fresh vn unit (vn7, vn8, ... appear in /dev). However the claimed permanent vnode leak is NOT observable: debug.numvnodes stayed flat at 98371 across the run and the created unit vnodes remain fully usable (ls and read-only open of /dev/vn7 succeed immediately - a permanently EXCLUSIVE-locked vp would block vget forever). On this guest the EPERM path did not strand a locked vnode.",
 "exploit_chain": "",
 "evidence": "VERDICT.md + run.log + sources",
 "kernel_refs": [
  "sys/vfs/devfs/devfs_vnops.c:1006",
  "sys/vfs/devfs/devfs_vnops.c:1013",
  "sys/vfs/devfs/devfs_vnops.c:933"
 ],
 "poc_changes": "adjusted from finding sketch to guest syscall/layout reality",
 "attempts": 1,
 "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64",
 "runtime_sec": 30,
 "guest_dirty": 0,
 "build_cmd": "guest: cc -O2 -o <bin> <src>.c -pthread",
 "run_cmd": "see README.md",
 "code_hash": "2231fbec8372238fb553658eab331a10e17c4aa464d118c02c72807a01e7ce40",
 "notes": "fix_status: not_testable (not reproduced)",
 "recommended_fix": "diff: vput(vp) before the three early returns in the D_DISK write-open block (mirroring the :992-998 EALREADY cleanup).\n"
}