Summary

The unregister path frees minor numbers by calling the allocator function devfs_clone_bitmap_get instead of the release function devfs_clone_bitmap_put. As a result, every register/unregister cycle leaks npins+1 minor-number bits, and once the bitmap is exhausted the next register triggers panic("devfs_clone_bitmap_fff") in devfs_helper.c:120.

Root cause

At gpio.c:596-600:

for (i = 0; i < gp->npins; i++) {
    devfs_clone_bitmap_get(&DEVFS_CLONE_BITMAP(gpio),
        minor(gp->pins[i].dev));
    destroy_dev(gp->pins[i].dev);
}

Per sys/vfs/devfs/devfs_helper.c:221-234, devfs_clone_bitmap_get(bitmap, limit) allocates the lowest free bit <= limit and marks it in-use (via devfs_clone_bitmap_set, devfs_helper.c:182); it does NOT free the supplied unit. The intended call is devfs_clone_bitmap_put(bitmap, minor(gp->pins[i].dev)) (devfs_helper.c:198-211), which sets the bit back to 1 (free). The bitmap is sized DEVFS_CLONE_BITMAP(gpio) from a flat namespace shared across all controllers, so repeated cycles leak the bitmap until devfs_clone_bitmap_fff cannot find a free bit and panics at devfs_helper.c:120 (panic("devfs_clone_bitmap_fff");).

Threat model & preconditions

• Attacker position: root (GPIO controller attach/detach is a privileged driver operation; gpio_unregister is called from controller driver detach, e.g. sys/dev/misc/nsclpcsio/nsclpcsio_isa.c).
• Privileges gained or impact: deterministic kernel panic after enough attach/detach cycles to exhaust the bitmap. Local privileged-user denial of service.
• Required config or capabilities: device gpio; ability to trigger repeated driver re-probes (kldload/kldunload of controller modules, ACPI device add/remove).
• Reachability: repeated register/unregister cycles of a GPIO controller.

Proof of concept

#!/bin/sh
# panic-gpio-bitmap.sh — leak the bitmap until devfs_clone_bitmap_fff panics
for i in $(seq 1 10000); do
    kldload nsclpcsio 2>/dev/null
    kldunload nsclpcsio 2>/dev/null
done

Expected output

panic: devfs_clone_bitmap_fff
...

Each kldload/kldunload cycle decreases the free count by npins+1 without ever restoring it. Panic after bitmap_size / (npins+1) iterations.

Impact

Low-severity (root-only trigger) but deterministic kernel panic. An obvious bug that maintainers should fix.

Recommended fix

Replace _get with _put and pass the actual minor of the device being destroyed, not a limit:

--- a/sys/dev/misc/gpio/gpio.c
+++ b/sys/dev/misc/gpio/gpio.c
@@ -595,8 +595,8 @@ gpio_unregister(struct gpio *gp)

    for (i = 0; i < gp->npins; i++) {
-       devfs_clone_bitmap_get(&DEVFS_CLONE_BITMAP(gpio),
-           minor(gp->pins[i].dev));
+       devfs_clone_bitmap_put(&DEVFS_CLONE_BITMAP(gpio),
+           minor(gp->pins[i].dev));
        destroy_dev(gp->pins[i].dev);
    }
+   devfs_clone_bitmap_put(&DEVFS_CLONE_BITMAP(gpio),
+       minor(gp->master_dev));
    destroy_dev(gp->master_dev);

The current master_dev minor (allocated at gpio.c:573) is also leaked today; the fix returns both pin minors and the master minor to the pool.

References

• devfs_clone_bitmap_get (allocates): devfs_helper.c:221-234.
• devfs_clone_bitmap_put (frees): devfs_helper.c:198-211.
• Panic site: devfs_helper.c:120.

Timeline

• 2026-07-20 Discovered during automated audit.
• 2026-07-20 Reported to DragonFlyBSD security contact (pending).