⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-3025

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

Field Value
ID DF-3025
Status new
Severity Low
CVSS 3.1 CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CWE CWE-364
File sys/vfs/tmpfs/tmpfs_vnops.c
Lines 1209-1228 (increment: tmpfs_subr.c:320)
Area vfs/tmpfs
Confidence speculative
Discovered 2026-09-02
Pass 2 (GLM 5.3 second pass)
Bucket base:vfs
Reported pending
Known CVE none
CVE match novel

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

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-3025 · 8 files
FileTypeDescriptionSize
README.md — 312 B ↓ raw
VERDICT.md — 1.3 KB ↓ raw
df3025.c — 2.6 KB view raw
env.txt — 248 B view raw
fix.diff — 99 B view raw
manifest.json — 517 B view raw
run.log — 240 B view raw
verdict.json — 1.6 KB view raw
README.md
↓ download raw

DF-3025 - tmpfs_nlink LINK_MAX check-then-increment race across directories

Severity Low | verdict: not_reproduced | impact: none

Reproduce

Sources in this directory; build with cc -O2 -o <bin> <src> -pthread on the guest.

See VERDICT.md for the full narrative and run.log for the decisive output.

VERDICT.md
↓ download raw

DF-3025 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

Setup to tn_links=32766 (LINK_MAX-1) succeeded, then two threads raced link() into two different directories across 200 + 600 rounds - first with a pthread barrier and a shared source path, then with distinct source hard-links (/L1 and /L993) to defeat namecache serialization. Every round came out complementary (errno pair 0/EMLINK or 31/0): exactly one link succeeded and the other got EMLINK, i.e. the tn_links check (tmpfs_vnops.c:1210) and the atomic_add in tmpfs_alloc_dirent (tmpfs_subr.c:320) never overlapped. The kernel-level serialization of both link() syscalls on the shared target vnode (vn_lock before VOP_NLINK) appears to make the window uncrossable from link(2) on this 6-vCPU guest; the source-level gap remains.

Kernel references

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.

Fix verification

not_testable
↓ fix.diffper-fix-DF-3025

Confirmed kernel references

Detail

Evidence (decisive lines)

VERDICT.md + run.log + sources

PoC changes

adjusted from finding sketch to guest syscall/layout reality

Verified recommended fix

diff: TMPFS_NODE_LOCK(node) around the LINK_MAX check (or clamp+rollback in tmpfs_alloc_dirent).

Verdict

Setup to tn_links=32766 (LINK_MAX-1) succeeded, then two threads raced link() into two different directories across 200 + 600 rounds - first with a pthread barrier and a shared source path, then with distinct source hard-links (/L1 and /L993) to defeat namecache serialization. Every round came out complementary (errno pair 0/EMLINK or 31/0): exactly one link succeeded and the other got EMLINK, i.e. the tn_links check (tmpfs_vnops.c:1210) and the atomic_add in tmpfs_alloc_dirent (tmpfs_subr.c:320) never overlapped. The kernel-level serialization of both link() syscalls on the shared target vnode (vn_lock before VOP_NLINK) appears to make the window uncrossable from link(2) on this 6-vCPU guest; the source-level gap remains.