DF-1090 — pnp_parse_desc accesses fixed descriptor offsets without length validation

Build

cc -O0 -o df1090_harness df1090_harness.c
cc -O0 -DFIX -o df1090_harness_fix df1090_harness.c

Run

./df1090_harness        # unpatched algorithm — 8/8 OOB
./df1090_harness_fix    # patched algorithm — 0/8 OOB
sh verify.sh            # 11 static source-tree checks

Expected (bug present)

• verify.sh reports PASS=11 FAIL=0 on the audit tree (the 8 missing guards are pinned, the ANSI control case is pinned, the function signature and call site are pinned).
• df1090_harness reports OOB DETECTED for all 8 descriptor types when fed a declared TLV length shorter than the offsets the parser accesses unconditionally.
• df1090_harness_fix reports no OOB for all 8 — each type now bails out cleanly on a short declared length.

Bug shape

pnp_parse_desc at sys/bus/isa/pnpparse.c:60-340 receives the resource pointer res and the attacker-declared TLV length len (the length field inside the TLV header, supplied by the PnP card itself). For every descriptor type except PNP_TAG_ID_ANSI (which correctly clamps len to sizeof(buf)-1 at line 224 before bcopy), the parser accesses fixed offsets of res without first checking that len is large enough:

The IO_RANGE case is the most interesting because line 165 performs an OOB write (res[5] = 1 as part of the align-normalization) when the declared length is < 6, which can escape the 1024-byte kmalloc bucket the resource buffer was allocated from by pnp_read_bytes.

Impact / preconditions

A malicious ISA-PnP card (or a hostile QEMU PnP device model) supplies crafted TLV data with a truncated length field. The PnP bus is probed at boot (pnp_identify → pnp_isolation_protocol → pnp_create_devices → pnp_parse_resources → pnp_parse_desc) and on kldload pnp. The audit guest has zero PnP cards, so the path is not exercised at runtime here; the bug is confirmed by source trace + userspace harness mirroring the algorithm.

DF-1090 — pnp_parse_desc fixed-offset accesses without length validation

Verdict

NOT REPRODUCED at runtime (hardware-gated) — STATIC VERIFICATION + HARNESS CONFIRMED.

The bug exists verbatim in sys/bus/isa/pnpparse.c:90-328. Every descriptor-type branch except PNP_TAG_ID_ANSI accesses fixed offsets of the resource buffer (res[N], I16(res+N), I32(res+N)) without first checking that the attacker-declared TLV length len is large enough — even though the parser is called with l (the length field from the TLV header, supplied by the PnP card) as the len argument (pnpparse.c:518,538).

The audit QEMU guest has no ISA-PnP cards (dmesg | grep -c pnp = 0), so pnp_identify finds nothing and pnp_parse_desc is never invoked at runtime. The trigger requires attacker-controlled PnP hardware (or a hostile QEMU PnP device model) — AV:P/AC:L. This is the same hardware constraint as the sibling finding DF-1071.

The df1090_harness userspace C program mirrors the parser algorithm byte-for-byte for all 8 affected descriptor types. Run with a declared length shorter than the offsets each type accesses, the unpatched algorithm reports OOB DETECTED for 8/8 cases; the patched algorithm (per-descriptor length guards) reports no OOB for 8/8.

Mechanism (confirmed by source trace)

pnp_parse_resources (pnpparse.c:408-545) iterates the TLV resource blob and for each tag extracts the declared length l:

/* small resource: */
l = PNP_SRES_LEN(tag);              /* :438 - 4 bits from the tag byte */
...
pnp_parse_desc(dev, tag, p, l, config, ldn);     /* :518 */

/* large resource: */
l = I16(p);                          /* :529 - 9 bits from card */
p += 2; len -= 2;
...
pnp_parse_desc(dev, tag, p, l, config, ldn);     /* :538 */

In both cases l is the length declared by the card, not validated against the descriptor type's required minimum. pnp_parse_desc then dispatches on the tag and accesses offsets of res:

case PNP_TAG_IO_RANGE:
    ...
    if (res[6] == 0) { ... }                       /* :141 — needs len >= 7 */
    ...
    I16(res + 1)                                    /* :154 */
    I16(res + 3) + res[6] - 1                       /* :155 */
    ...
    if (res[5] == 0) { res[5] = 1; }                /* :163-165 — OOB WRITE */

A malicious card sets the PNP_TAG_IO_RANGE length field to 3, sends 3 payload bytes, and the parser reads res[6] (3 bytes past end), I16(res+1) (1 byte past end), I16(res+3) (3 bytes past end), and writes res[5] = 1 (2 bytes past end). On the kmalloc(1024) buffer the resource data lives in, an attacker within 17 bytes of the 1024-byte boundary writes outside the allocation entirely.

The PNP_TAG_ID_ANSI case at :223-235 is the control — it correctly clamps len before its bcopy. Every other type lacks that clamp.

Reproduction

$ sh verify.sh        # 11/11 static checks pin the missing guards
$ cc -O0 -o df1090_harness df1090_harness.c
$ cc -O0 -DFIX -o df1090_harness_fix df1090_harness.c
$ ./df1090_harness        # 8/8 "OOB DETECTED"
$ ./df1090_harness_fix    # 8/8 "no OOB"

Fix

fix.diff adds a single if (len < N) break; guard at the head of each of the 8 affected descriptor-type branches, using the minimum length that type's accesses require (4, 2, 1, 7, 3, 9, 17, 9 respectively). The guards mirror the existing PNP_TAG_ID_ANSI clamp in spirit: if the card-declared length is too short for the descriptor type, skip it rather than read past the buffer. The kernel nativekernel build of the patched file succeeds (fix_build.log, NK_DONE rc=0); the harness proves the fix is correct at the algorithm level.