Summary

When gpio_map walks the bit mask and finds an invalid/bad pin mid-loop, it bails out and frees the mapping, but it leaves pin_mapped = 1 set on every pin that was successfully processed before the bad one. Those pins are then permanently unusable (every subsequent open/map returns EBUSY), because nothing ever clears the stuck pin_mapped bit.

Root cause

At gpio.c:211-226:

for (npins = 0, i = 0; i < 32; i++)
    if (mask & (1 << i)) {
        pin = offset + i;
        if (pin < 0 || pin >= gp->npins ||
            gp->pins[pin].pin_mapped || gp->pins[pin].pin_opened) {
            ...
            return NULL;            /* <-- bail without unwinding */
        }
        gp->pins[pin].pin_mapped = 1;   /* <-- sticky side-effect */
        gmp->map[npins++] = pin;
    }

If bit i=0 succeeds (sets pin_mapped on offset+0) and bit i=1 fails (because offset+1 >= gp->npins), the loop returns NULL but gp->pins[offset].pin_mapped stays 1 forever. The correct behavior is either to roll back the side effect before returning, or to validate the entire mask first and only then commit.

gpio_unmap (gpio.c:236-260) clears pin_mapped via gmp->map[], but since the failing path never returns a gmp, nothing can call gpio_unmap.

Threat model & preconditions

• Attacker position: root (GPIOATTACH ioctl on the root-only master device, gpio.c:471-478).
• Privileges gained or impact: permanent pin lockout. Recoverable only by unregistering/re-registering the controller.
• Required config or capabilities: device gpio; root access to the master device; a multi-bit-mask consumer (the only in-tree caller led_attach gpio_led.c:197 passes a single-bit mask mask=1 and cannot trigger this).
• Reachability: gpio_map is an exported symbol (gpio.h:143); any future consumer passing a multi-bit mask with a pin_offset + i that crosses gp->npins would trigger it.

Proof of concept

Latent (only single-bit caller in-tree). Triggerable once a multi-bit consumer exists:

/* From userspace as root, force the partial-failure path: */
struct gpio_attach_args a = {
    .consumer_name = "my",
    .pin_offset    = gp->npins - 1,   /* last valid pin */
    .pin_mask      = 0x3,             /* two bits: offset+0 valid, offset+1 OOB */
    .arg_type      = GPIO_TYPE_INT
};
ioctl(master_fd, GPIOATTACH, &a);     /* fails — but pin (npins-1) stuck mapped */
/* subsequent open of /dev/gpio/.../N for that pin returns EBUSY forever */

Expected output

After the failed attach, open("/dev/gpio/<drv>0/<last>", O_RDWR) returns EBUSY even though no consumer is attached.

Impact

Low-severity (latent) pin lockout. No in-tree caller can trigger it today; it becomes exploitable if a multi-bit GPIO consumer is ever added.

Recommended fix

Validate the entire mask first, or roll back on failure. Minimal rollback fix: when the caller passed map == NULL, free gmp->map and gmp, then walk the pins already marked and clear pin_mapped for each. Set gmp->size = npins inside the loop after each successful pin (also fixes the latent issue that gmp->size is only set at gpio.c:227 after the loop, so a parallel caller could see size=0 and skip the unmap).

Timeline

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