devfs_allocv failure ignored: devfs_spec_open and devfs_vop_nlookupdotdot use the vp unconditionally → vn_unlock(NULL)/NULL-fp panic under vnode exhaustion

Summary

devfs_allocv can return an error leaving vpp=NULL. devfs_vop_nlookupdotdot:535-536 then vn_unlock(a_vpp) on NULL; in devfs_spec_open's clone path the (ignored) failure leaves vp=NULL, ap->a_vp=NULL, and :978 vn_unlock(vp=NULL) — kernel NULL-deref panic. Requires getnewvnode/vget failure — forceable via vnode-cache exhaustion pressure by an unprivileged user, otherwise rare; impact is a panic. Not executed (exhaustion setup time-heavy); code-path direct. Fix: check devfs_allocv's return (bail ENOENT in nlookupdotdot; treat clone allocv failure as failed clone in spec_open).

Timeline

• 2026-09-02 Discovered during pass-2 audit of devfs_vnops.c (GLM 5.3).