# DF-3019 verification

Kernel: 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

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.

## Kernel references
- sys/vfs/devfs/devfs_vnops.c:1006
- sys/vfs/devfs/devfs_vnops.c:1013
- sys/vfs/devfs/devfs_vnops.c:933

## Fix
See 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.