tmpfs_nlink LINK_MAX check-then-increment race across different directories can push tn_links past LINK_MAX → KKASSERT panic (INVARIANTS) / nlink contract breach

Summary

tmpfs_nlink checks node->tn_links >= LINK_MAX while holding only the target DIRECTORY's lock; the increment happens later in tmpfs_alloc_dirent via atomic_add with no node-level serialization. Two threads linking the same file into two different directories (different dnode locks) can both pass the check and both increment, pushing tn_links to LINK_MAX+1. tmpfs_alloc_dirent's M_WAITOK kmallocs widen the race window (sleeps inside it). Any subsequent nlink on that file then trips KKASSERT(node->tn_links <= LINK_MAX) on INVARIANTS kernels (panic); production kernels merely return EMLINK, leaving an st_nlink > LINK_MAX POSIX breach. Prerequisites: ~32760 setup link() calls plus several precisely racing threads; probabilistic. Untested (race, non-deterministic). Fix: serialize the check with the increment (TMPFS_NODE_LOCK around the check) or clamp in tmpfs_alloc_dirent with rollback.

Timeline

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