DF-4752 — gpio(4) gpio_unregister leaks the master clone unit + struct gpio_driver

File: sys/dev/misc/gpio/gpio.c (pass 2)

What

gpio_unregister() (gpio.c:587-617) has two resource-accounting defects that are distinct from the known pin-unit get-vs-put bug (DF-1845, gpio.c:596-600):

1. Master device clone unit never returned. gpio_register() allocates a unit from DEVFS_CLONE_BITMAP(gpio) for the master cdev (gpio.c:573-575, make_dev(..., "gpio/%s%d/master", ...)). gpio_unregister() destroys that dev (gpio.c:602) but never calls devfs_clone_bitmap_put() for it — the unit stays allocated forever. (The pin loop right above at least attempts a bitmap call, albeit the wrong one.)

2. struct gpio_driver + name never freed, dropped from the list while siblings may still use it. gpd is allocated once per driver name (gpio.c:559-565, shared by all controllers with the same driver_name; gpd->name = kstrdup(...)). gpio_unregister() does devfs_clone_bitmap_put(&gpd->unit_bitmap, ...); LIST_REMOVE(gpd, link); (gpio.c:609-611) with no kfree of gpd or gpd->name, and no refcount: - every unregister leaks sizeof(struct gpio_driver) + name (M_TEMP); - if two controllers share the name, the first unregister unlinks the shared gpd while the sibling is still live; the sibling's own unregister then finds no list entry and silently skips its bitmap put.

Impact

Permanent kernel heap leak per controller attach/detach cycle plus monotonic clone-unit consumption (the bitmap auto-extends — devfs_clone_bitmap_get() is called with limit 0, which never fails — so this is unbounded creep, not a hard exhaustion). Trigger is privileged (driver detach / kldunload), hence Low severity, consistent with the DF-1845/DF-1846 family.

Reproduce (hardware/config-gated)

Run ./trigger.sh on a system with device gpio + a GPIO controller (nsclpcsio/PC87366 etc.). On the audit guest the framework is not compiled in (optional gpio, not in X86_64_GENERIC), so the trigger exits 3 (SKIP) — defect verified by source trace; fix compile-validated (see VERDICT.md).

Fix

fix.diff (applies to sys/dev/misc/gpio/gpio.c): put the master unit back, refcount gpd, free on last reference. Compile-validated as a kernel module against the guest's 6.5-DEVELOPMENT source with -Werror (fix_build.log).

DF-4752 VERDICT

Status: INCONCLUSIVE (runtime) — defect certain by source trace; fix compile-validated. Runtime reproduction is hardware/kernel-config-gated on the audit guest.

Impact: Low — permanent kernel heap leak (struct gpio_driver + name + one clone-bitmap word per cycle) on every GPIO controller detach/re-attach. Privileged trigger only (driver detach / module unload). No memory-safety consequence; same severity family as DF-1845/DF-1846.

Why it is real (source trace)

• gpio.c:573 unit = devfs_clone_bitmap_get(&DEVFS_CLONE_BITMAP(gpio), 0); — master unit allocated; gpio.c:574-575 make_dev(..., unit, ... "gpio/%s%d/master", ...).
• gpio.c:596-602 (unregister): the pin loop calls the bitmap (wrongly — DF-1845, known, NOT re-reported) and destroy_dev(gp->master_dev); at gpio.c:602 — no devfs_clone_bitmap_put for the master's unit anywhere in the function (verified by reading the whole function and by rg devfs_clone_bitmap over the file: register = 3 gets, unregister = 1 get(bug) + 1 put(driver_unit)).
• gpio.c:552-566 (register): one gpd per driver name; second controller of the same name reuses it (master_unit = devfs_clone_bitmap_get(...)), no refcount kept.
• gpio.c:604-613 (unregister): LIST_REMOVE(gpd, link); break; — gpd and gpd->name never kfreed (leak), and the unlink happens even when sibling controllers of the same name are still registered (they lose their put).
• devfs_clone_bitmap_get(bitmap, 0) (sys/vfs/devfs/devfs_helper.c): with limit == 0 the unit > limit guard is disabled → never returns -1; the bitmap auto-extends → consequence is unbounded unit-space/heap creep, not allocation failure.

Verification performed on the guest

1. Feature-gating confirmed (run.log): /dev/gpio* absent; no /boot/kernel/gpio.ko; sys/dev/misc/gpio/gpio.c is optional gpio (sys/conf/files:2119) and X86_64_GENERIC has no device gpio → the framework cannot be instantiated on this guest (needs a kernel with device gpio plus a controller such as nsclpcsio/PC87366 hardware).
2. Fix compile-validated: baseline gpio.c and fix.diff-patched gpio.c both built as KLD modules against the guest's pristine /usr/src (DragonFly 6.5-DEVELOPMENT) with -Werror: * build.log (baseline) — rc=0 * fix_build.log (patched) — rc=0
3. sys/ tree untouched; guest /usr/src restored and hash-verified (c93a0e25… for gpio.c, 3c863567…/22808bde… for cxm.h/cxm.c) after the fix build.

Fix

fix.diff: add refs to struct gpio_driver, increment on reuse, devfs_clone_bitmap_put() the master unit after destroy_dev(), and kfree() gpd+name when the last reference drops.

Baseline vs patched

Not runtime-testable on this guest (feature absent). The patch is a pure resource-accounting change; both variants compile clean with -Werror. fix_status=inconclusive (build verified, behavior hardware-gated).

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.