DF-5179 — atkbd(4) ISA attach: unchecked IRQ resource allocation → boot-time kernel panic

• File: sys/dev/misc/atkbd/atkbd_isa.c
• Severity: Low (boot-time DoS; trigger requires privileged config / resource exhaustion)
• Confidence: certain (source-proven panic path)
• Verification: source-confirmed only — trigger is boot-time and gated on kernel-config/loader hints (root-only) or ISA IRQ rman exhaustion; there is no unprivileged runtime entry point to exercise in the QEMU guest, so no guest run was attempted (verdict.json status untested, attempts 0).

Root cause

atkbdattach() (sys/dev/misc/atkbd/atkbd_isa.c:118-124) allocates the legacy IRQ resource and hands it straight to BUS_SETUP_INTR() without any NULL check:

rid = 0;
sc->intr = bus_alloc_legacy_irq_resource(dev, &rid, irq, RF_ACTIVE);
BUS_SETUP_INTR(device_get_parent(dev), dev, sc->intr, INTR_MPSAFE,
               atkbd_isa_intr, kbd, &sc->ih, NULL, NULL);

Three things go wrong when the allocation fails:

1. sc->intr == NULL is forwarded down the bus tree (atkbdc → bus_generic → isa → nexus) and nexus_setup_intr() panics on NULL by design — sys/platform/pc64/x86_64/nexus.c:505-506:

c /* somebody tried to setup an irq that failed to allocate! */ if (irq == NULL) panic("%s: NULL irq resource!", __func__);

A driver-caused NULL irq is supposed to be a driver bug caught before this point; atkbd_isa is exactly such an unchecked driver.

2. Even for the non-NULL late-failure path (register_int() returns NULL → EINVAL), the BUS_SETUP_INTR() return value is ignored, the irq resource is leaked, and atkbdattach() still return 0 — the driver reports a healthy attach with no interrupt plumbed.

3. atkbdresume() (atkbd_isa.c:141) later calls rman_get_start(sc->intr) which dereferences the resource pointer ((r)->r_start) — a second NULL-deref site if the attach bug is ever fixed by ignoring the error instead of failing the attach.

Trigger path

irq comes from the parent atkbdc ivar. When no hint.atkbd.N.irq hint exists, atkbdc_add_device() initializes it to -1 (sys/dev/misc/atkbdc_layer/atkbdc_isa.c:221-224), which is passed as (u_long)-1 to bus_alloc_legacy_irq_resource() → BUS_ALLOC_RESOURCE(..., start = ULONG_MAX, end = ULONG_MAX, ...) → the ISA IRQ rman cannot satisfy the range → NULL → panic above. IRQ rman exhaustion/conflict at boot is an alternative route to the same NULL.

Default configs pin the irq (sys/config/X86_64_GENERIC:152: device atkbd0 at atkbdc? irq 1), so the panic needs a custom kernel config / /boot/loader.conf hints (root-only) or IRQ pressure — hence Low.

In-tree reference for the correct pattern

The sibling driver on the same parent does it right (sys/dev/misc/psm/psm.c:2014-2022):

sc->intr = bus_alloc_legacy_irq_resource(dev, &rid, irq, RF_ACTIVE);
if (sc->intr == NULL) {
        return (ENXIO);
}

error = BUS_SETUP_INTR(device_get_parent(dev), dev, sc->intr,
                INTR_NOPOLL, psmintr, sc, &sc->ih, NULL, NULL);
if (error)
        goto out;

Fix

fix.diff in this directory — NULL-check the allocation (return ENXIO), check the BUS_SETUP_INTR() result, unwind the resource on failure. Not applied to sys/ (audit tree is read-only); not guest-validated (fix_status: not_testable — trigger is boot-config-gated).

Artifacts

• VERDICT.md — this narrative
• trigger.txt — the privileged config that triggers the panic
• fix.diff — the verified-by-inspection fix
• manifest.json, verdict.json

DF-5179 — Verification Verdict

Status: untested (source-confirmed; boot-config-gated — no unprivileged or guest-runnable trigger exists) Impact: panic (boot-time kernel panic when triggered) Confidence: certain Attempts: 0 (no runtime attempt — see below)

Why the code path is proven without a guest run

Every link in the chain is visible in the tree:

1. atkbdattach() passes the parent ivar irq to bus_alloc_legacy_irq_resource() and forwards the unchecked result to BUS_SETUP_INTR() — sys/dev/misc/atkbd/atkbd_isa.c:119-122.
2. With no hint.atkbd.N.irq, the parent initializes the ivar to -1 (sys/dev/misc/atkbdc_layer/atkbdc_isa.c:221-224), which becomes (u_long)-1 in BUS_ALLOC_RESOURCE(..., start=ULONG_MAX, end=ULONG_MAX, ...) (sys/kern/subr_bus.c:3303-3310) — an ISA IRQ rman range that can never be satisfied → returns NULL.
3. BUS_SETUP_INTR walks atkbdc (bus_generic) → isa (sys/bus/isa/x86_64/isa.c:143-149) → nexus, and nexus_setup_intr() executes panic("%s: NULL irq resource!", __func__) on the NULL resource — sys/platform/pc64/x86_64/nexus.c:505-506.
4. Secondary NULL-deref site: atkbdresume() dereferences rman_get_start(sc->intr) (sys/dev/misc/atkbd/atkbd_isa.c:141).
5. Sibling driver on the same bus checks both conditions (sys/dev/misc/psm/psm.c:2014-2022) — atkbd_isa.c is the outlier.

Why no guest run

The trigger is boot-time and requires either a kernel config/loader hint without irq 1 (root-only file edits + reboot, risking an unbootable console-less guest) or ISA IRQ rman exhaustion. There is no runtime syscall, ioctl, or device node that reaches this path after boot completes, so a QEMU PoC would be testing the guest's own boot configuration rather than an attacker-reachable primitive. Marked untested rather than not_reproduced because the proof is static, per the family precedent (DF-2177/DF-2178/DF-2385 were likewise source-confirmed).

Fix validation

fix.diff (in this directory) adds the NULL check (ENXIO) and the BUS_SETUP_INTR error check with resource unwind. Verified to apply cleanly (patch -p1 --dry-run OK against a pristine copy of the file). Kernel build/boot validation not performed (Low severity, boot-gated trigger): fix_status: not_testable.

Source File

sys/dev/misc/atkbd/atkbd_isa.c

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.