DF-3006 — nlinks double-decrement on rule-link reset leaks the target devfs node forever

• Files: sys/vfs/devfs/devfs_rules.c:222-226 (extra decrement) + sys/vfs/devfs/devfs_core.c:729,610-618 (devfs_gc -> devfs_unlinkp performs the legitimate decrement)
• Class: CWE-670 / resource leak via incorrect bookkeeping
• Severity: Low (memory leak; no memory-safety consequence — the size_t underflow makes nlinks wrap far from 0, so no premature free)
• Reach: root (devfsctl / DEVFS_RULE_RESET ioctl; also any jail whose devfs ruleset is reset).

Build

sh leak.sh 300      # compiles leak.c (plain ioctls on /dev/devfs)

Run / expected

== baseline M_DEVFS usage ==
              devfs     888    130K       0    390M      903
== running 300 iterations (with DEVFS_RULE_RESET => double decrement) ==
== M_DEVFS usage after bugged loop ==
              devfs   1.66K    251K       0    390M     120K
== control: 300 iterations WITHOUT reset ==
== M_DEVFS usage after control loop ==
              devfs   1.65K    249K       0    390M     239K

~400 bytes leaked per mount+RULE_RESET+umount cycle (sizeof(struct devfs_node) + its d_dir.d_name kmalloc), while the identical loop without DEVFS_RULE_RESET is flat. Full run captured in run.log.

Mechanism

1. Rule LINK creates an Nlink node L with L->link_target = T and T->nlinks++ (devfs_core.c:1894-1895).
2. DEVFS_RULE_RESET walks the topology calling devfs_rule_reset_node (devfs_rules.c:213): for rule-created links it executes --node->link_target->nlinks; and then devfs_gc(node).
3. devfs_gc(L) -> devfs_unlinkp(L) (devfs_core.c:729, 566) hits the Nlink branch and decrements target->nlinks a second time (devfs_core.c:614).
4. T->nlinks (size_t) underflows to (size_t)-1 and can never reach 0 again.
5. At unmount, the reaper's devfs_freep(T) sees nlinks != 0, sets DEVFS_NLINKSWAIT, and never calls objcache_put (devfs_core.c:526-527): node + name leak permanently. leak_count stays balanced (it is decremented in the same pass), so the "Leaked N devfs_node elements!" warning at DEVFS_MOUNT_DEL does not fire — the leak is silent.

Fix

fix.diff deletes the redundant decrement in devfs_rule_reset_node; devfs_gc/devfs_unlinkp already does exactly one decrement per removed link, matching every other link-removal path. Validated on the patched kernel (fix/ outputs): leak loop goes flat.

DF-3006 VERDICT

Status: reproduced — impact: silent kernel memory leak (~400 B/cycle, unbounded, root-triggerable).

Reproduction

Guest DragonFly 6.5-DEVELOPMENT #0, root. leak.sh (this pack):

• leak.c opens /dev/devfs and issues the stock rule ioctls: DEVFS_RULE_ADD (NAME vn0, LINK leaklink, mntpoint /mnt/dt), then per iteration mount -t devfs df3006 /mnt/dt (node creation auto-applies the rule -> devfs_alias_create(..., rule_based=1) -> target->nlinks = 1, devfs_core.c:1895), DEVFS_RULE_RESET (fires devfs_rule_reset_node), umount /mnt/dt.
• 300 bugged iterations: M_DEVFS 888 allocs/130K -> 1.66K allocs/251K (+~780 allocations, +121K, ≈400 B per cycle = sizeof(struct devfs_node) + the d_dir.d_name kmalloc that devfs_freep skips under DEVFS_NLINKSWAIT).
• 300 control iterations (no RESET): 251K -> 249K — flat. Deterministic difference, single variable (the RESET ioctl).

Root cause (lines)

• sys/vfs/devfs/devfs_rules.c:222-226: reset decrements node->link_target->nlinks and then calls devfs_gc(node).
• sys/vfs/devfs/devfs_core.c:729: devfs_gc -> devfs_unlinkp(node).
• sys/vfs/devfs/devfs_core.c:610-618: devfs_unlinkp Nlink branch decrements target->nlinks again (this is the correct, universal decrement used by every other link-removal path).
• sys/vfs/devfs/devfs_core.c:526-527: devfs_freep with nlinks != 0 (size_t underflow, can never return to 0) sets DEVFS_NLINKSWAIT and never frees -> node + name leaked. leak_count is decremented in the same pass (devfs_core.c:466), so the DEVFS_MOUNT_DEL warning at 1330-1334 never fires — the leak is silent.

Why not higher severity

• No memory-safety consequence: the underflow drives nlinks away from 0, so the target->nlinks == 0 && DEVFS_DESTROYED premature-free branch (devfs_core.c:615-618) can never be taken via this bug; the result is a pure allocation leak.
• Trigger requires root (rule ioctls on /dev/devfs are privileged; jail devfs ruleset resets are system-initiated).
• Unbounded but slow: each cycle needs a mount/umount; a jailed service churning devfs mounts with rules could accumulate over time.

Fix validation

Applied fix.diff (delete the manual decrement in devfs_rule_reset_node; devfs_gc->devfs_unlinkp provides the single legitimate decrement) in the guest /usr/src, rebuilt with make nativekernel, installed, rebooted. Re-ran leak.sh 300 on the patched kernel: M_DEVFS stays flat across the bugged loop (see fix/fix_run.log), control unchanged. Fixed.