Server attributes freely retype live vnodes in nfs_loadattrcache (VREG→VDIR observed live; VCHR/VBLK with server-chosen rdev via addaliasu + v_ops switch) — device-node injection and buffer-cache type confusion through every attribute load in this file

Summary

Every nfsm_loadattr/nfsm_postop_attr/nfsm_wcc_data call in nfs_vnops.c funnels into nfs_loadattrcache, which for an EXISTING vnode executes 'if (vp->v_type != vtyp) { nfs_setvtype(vp, vtyp); vp->v_ops = &...mnt_vn_spec_ops; addaliasu(vp, rmajor, rminor); }' with vtyp/rmajor/rminor straight from the wire. There is no 'only set type at creation' guard. OBSERVED LIVE during DF-2996 verification: a single LOOKUP reply with directory-typed attributes for the file's own file handle retyped an open VREG vnode to VDIR mid-life and turned its reclaim into the fatal cookie-walk. Beyond that vector, a malicious server can flip any file on its share to VCHR/VBLK with an arbitrary server-chosen major/minor, delivering device nodes with server-chosen mode/uid through ordinary attribute replies — nfsv3tov_type's &0x7 table bounds the enum, so the confusion is fully type-safe from the server's perspective. Malicious NFS server + local user (or root) touching the share: (a) retype VREG→VDIR/VCHR on live vnodes corrupts buffer-cache/vmio assumptions; (b) VCHR/VBLK injection with server-chosen rdev exposes local device access with server-chosen permissions. Not separately PoC'd beyond the live VREG→VDIR retype that served as DF-2996's crash enabler. Fix: only assign v_type at node creation (vp->v_type == VNON); on type change of an existing vnode, invalidate the node (n_attrstamp=0, NRMODIFIED, purge namecache) instead of retyping.

Timeline

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