DF-4302 — vkbd devfs clone unit numbers are never released (unbounded, permanent leak)

Finding

vkbd_dev_clone() (sys/dev/misc/vkbd/vkbd.c:222-231) allocates a unit from the devfs clone bitmap on every open of the /dev/vkbdctl alias:

    int unit = devfs_clone_bitmap_get(&DEVFS_CLONE_BITMAP(vkbd), 0);
    ap->a_dev = make_only_dev(&vkbd_dev_cdevsw, unit, ...);

but vkbd_dev_close() (vkbd.c:288-334) — the only teardown path for a cloned unit — calls destroy_dev(dev) and never calls devfs_clone_bitmap_put(&DEVFS_CLONE_BITMAP(vkbd), unit). With limit == 0 (unbounded, devfs_helper.c:221-237), every open/close cycle permanently consumes one unit number and grows the kernel-side bitmap: a vkbd consumer that reconnects (desktop input bridges, VM input passthrough) leaks unit numbers for the uptime of the system.

Reproduced (live, guest)

DragonFly 6.5-DEVELOPMENT X86_64_GENERIC, 6 vCPU, kldload vkbd:

highest vkbdctl unit before: -1          (no node: everything closed)
vkbdctl unit handed out after 1000 full open/write/close cycles: 117699
units leaked: 117700

1000 fully-closed cycles advanced the allocator to unit 117,699 (the earlier missed-wakeup hammer on the same boot had already consumed ~116,699 the same way — ~90k of those within ~6 minutes at ~250 cycles/s). The counter never rewinds; nodes are removed by destroy_dev but the numbers are gone forever, and the bitmap (and unit number magnitude) grow without bound.

Run: build.sh / run.sh (trigger: vkbd_unit_leak.c).

DF-4302 verdict

Reproduced?

YES — reproduced live on the audit guest (status reproduced, impact dos-adjacent resource exhaustion, severity Low).

Trigger: vkbd_unit_leak.c — scans /dev for the highest vkbdctlN, performs 1000 completely balanced open("/dev/vkbdctl")/write/close cycles, then opens once more and re-scans.

Observed (run.log): before: -1 (no vkbdctlN node — prior cycles all closed) after 1000 closed cycles + probe open: unit 117699 handed out. => every cycle permanently consumed a unit number. Cumulative on this boot: ~116,699 units burned by earlier hammers (~90k in ~6 min at ~250 cycles/s), matching 1 unit per open regardless of close.

Root cause (path:line)

• sys/dev/misc/vkbd/vkbd.c:225 — devfs_clone_bitmap_get(..., 0) allocates; limit 0 => unbounded (sys/vfs/devfs/devfs_helper.c:221-237).
• sys/dev/misc/vkbd/vkbd.c:316-328 — close resets queue, tears down kbd, destroy_dev(dev), but never devfs_clone_bitmap_put(...) (contrast: devfs_core.c:2672 shows the intended put pattern).

Impact

Unbounded kernel resource-number leak on the device's normal lifecycle; bitmap chunks (kmalloc'd, devfs_helper.c) grow forever; /dev/vkbdctlN naming becomes unstable for tooling; combined with keyboard_info_t kb_unit lookups the namespace grows monotonically per boot. Requires the control node (root), hence Low.

Fix

Put the unit back in vkbd_dev_close (see fix.diff). Note destroy_dev() may be async in devfs; the put is idempotent-safe under devfs_bitmap_lock.

Fix validation

Not rebuilt (Low severity, non-corruption): the one-line fix directly closes the missing put; validated by inspection that no other consumer of the vkbd bitmap exists (only vkbd_dev_clone's get and destroy_autoclone_dev at MOD_UNLOAD, which resets the whole bitmap).

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.