# DF-3020 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

Two attempts to force getnewvnode failure inside the ptmx clone path: (1) kern.maxvnodes=300 with 217,405 open/close cycles - zero failures, vnlru kept recycling; (2) kern.maxvnodes=120 while holding 1,001 ptmx fds open - further opens fail with ENODEV from the pty driver unit limit (bitmap exhausted near 1000 units), which fires inside the clone handler BEFORE devfs_allocv, so the ignored-error path is never reached. The NULL-deref code path is real (devfs_allocv can return error leaving *vpp NULL; devfs_vop_nlookupdotdot:535 and devfs_spec_open:933 ignore the return) but getnewvnode could not be made to fail from unprivileged pressure on this guest.

## Kernel references
- sys/vfs/devfs/devfs_vnops.c:535
- sys/vfs/devfs/devfs_vnops.c:933
- sys/vfs/devfs/devfs_core.c:328

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