Summary

The trailing-space trim loop after the ANSI-string bcopy has no lower bound on large_len. A malicious PnP card can return a PNP_TAG_ID_ANSI large tag with length 0 (or a payload consisting entirely of 0x20 spaces), causing the loop to evaluate buf[large_len-1] with large_len == 0 (i.e. buf[-1]) and decrement without limit, walking the stack below char buf[100]. The terminating buf[large_len] = '\0' then writes a NUL at the resulting negative index.

Root cause

/* pnp.c:398-411 */
if (PNP_LRES_NUM(tag) == PNP_TAG_ID_ANSI) {
    if (large_len > sizeof(buf) - 1)
        large_len = sizeof(buf) - 1;
    /* !!! no `if (large_len == 0) continue;` lower bound */
    bcopy(resinfo, buf, large_len);

    /*
     * Trim trailing spaces.
     */
    while (buf[large_len-1] == ' ')     /* reads buf[-1] when large_len==0 */
        large_len--;
    buf[large_len] = '\0';              /* writes NUL at the resulting negative index */
    desc = buf;
    ...
    device_set_desc_copy(dev, desc);    /* strlen() of possibly-uninitialised buf */
}

large_len is card-controlled (16-bit, pnp.c:387). The clamp if (large_len > sizeof(buf) - 1) large_len = sizeof(buf) - 1; (line 399-400) only enforces an upper bound of 99; it never enforces a lower bound. With large_len == 0 the loop while (buf[large_len-1] == ' ') large_len--; (line 406-407) immediately evaluates buf[-1], then buf[-2], etc., each read being a stack OOB read below buf (other locals of pnp_create_devices live there: desc, csnldn, ldn, logical_id, large_len itself, retval, plus caller frame). The loop only stops when a non-0x20 byte is found. Then buf[large_len] = '\0'; (line 408) writes a NUL at the (possibly negative) resulting index — a stack OOB write conditional on the prior OOB byte being 0x20. Even if no write occurs, desc = buf (line 409) followed by device_set_desc_copy(dev, desc) (line 411) strlen()s the uninitialized buf[0..] (bcopy wrote 0 bytes), leaking stack contents through the device description.

Threat model & preconditions

• Attacker position: Malicious ISA-PnP card / QEMU-emulated device, same as DF-1071.
• Privileges gained or impact: Kernel stack memory disclosed via devinfo / dmesg description strings (CWE-909 / CWE-125), plus a conditional single-byte stack OOB NUL write (CWE-787) at the first 0x20 byte found below buf; in principle a long run of 0x20 bytes (e.g. on a specially groomed stack) could extend the write further down, but the typical effect is a 1-byte stack corruption or an info leak of one or more stack bytes.
• Required config or capabilities: Default kernel with ISA PnP. Card must pass isolation (see DF-1071).
• Reachability: pnp_isolation_protocol → pnp_create_devices at every boot. Trigger: return a large tag with PNP_LRES_NUM == PNP_TAG_ID_ANSI (0x02, i.e. tag byte 0x82) and length 0 (two zero length bytes), or any ANSI payload composed entirely of 0x20.

Proof of concept

Minimum PoC resource blob returned by a malicious card after a successful isolation: 82 00 00 — i.e. PNP_TAG_ID_ANSI large tag (0x82) with 16-bit length field 0x0000 and zero payload bytes, followed by 79 (PNP_TAG_END, small tag, len 0).

Implement a QEMU ISA-PnP model whose resource-data READ returns 82 00 00 79 after the card has won isolation; boot DragonFlyBSD with the model attached.

Build & run

# Implement a QEMU isa-pnp model returning the byte stream above, then:
qemu-system-x86_64 -enable-kvm -m 512 -hda dfbsd.img -device isa-pnp-custom

Expected output

• (a) The OOB read of buf[-1] (and possibly buf[-2].. if those stack bytes happen to be 0x20).
• (b) The device description string for the matching PnP child will then contain uninitialized stack bytes — visible in devinfo -v and dmesg.
• (c) If any of those bytes equals 0x20, buf[large_len] = '\0' writes a NUL one or more bytes below buf on the kernel stack, potentially corrupting a local variable or saved register, with outcomes ranging from silent corruption to kernel panic on return.

A purely emulator-driven demonstrator (no real hardware) is the most reproducible form: a QEMU patch returning 82 00 00 from PNP_RESOURCE_DATA after the card has won isolation.

Impact

Kernel stack info leak + conditional 1-byte stack OOB NUL write from a malicious ISA-PnP device during boot. Physical plug-in precondition; CVSS AV:P. Medium severity per "info leak of kernel stack" + possible stack corruption.

Recommended fix

Bound the trim loop below and skip the bcopy / desc path when large_len is 0:

--- a/sys/bus/isa/pnp.c
+++ b/sys/bus/isa/pnp.c
@@ -398,7 +398,9 @@
            if (PNP_LRES_NUM(tag) == PNP_TAG_ID_ANSI) {
                if (large_len > sizeof(buf) - 1)
                    large_len = sizeof(buf) - 1;
+               if (large_len == 0)
+                   continue;
                bcopy(resinfo, buf, large_len);

                /*
                 * Trim trailing spaces.
                 */
-               while (buf[large_len-1] == ' ')
+               while (large_len > 0 && buf[large_len-1] == ' ')
                    large_len--;

This both prevents the buf[-1] read and stops the loop from running away past buf[0].

References

• sys/bus/isa/pnp.c:398-411 — ANSI tag handling (the bug)
• sys/bus/isa/pnp.c:387 — large_len is card-controlled
• CWE-125 Out-of-bounds Read
• CWE-787 Out-of-bounds Write

Timeline

• 2026-07-14 Discovered during automated audit.