DF-2316 VERDICT -- pnp_parse_desc fixed-offset reads without declared-length validation

Status: REPRODUCED (byte-attributed OOB reads up to 17 bytes, heap past-allocation read through the real entry point, heap-residue leak into resource configs, conditional 1-byte OOB write, and a fatal page fault at a page boundary). Fix validated on a rebuilt kernel: bad behavior gone, well-formed streams bit-identical.

Root cause (path:line)

pnp_parse_desc() (sys/bus/isa/pnpparse.c:60-340) switches on the resource tag and dereferences FIXED offsets of the descriptor body res without ever comparing the declared length len against the accessed width:

The only length checks are in the callers and compare the REMAINING STREAM against the card-declared l (pnpparse.c:439 if (len < l), :532 if (len < l); pnp_scan_resources :581, :594) -- they guarantee the declared bytes exist, they say nothing about the handler reading beyond them. Real call path: pnp_isolation_protocol (pnp.c:594) -> pnp_read_resources (pnp.c:536, buffer kmalloc'd/realloc'd by pnp_read_bytes pnp.c:503/510 in 1024-byte M_TEMP chunks) -> pnp_create_devices (pnp.c:406) -> pnp_parse_resources (pnp.c:434/:469) -> pnp_parse_desc (pnpparse.c:518/:538). A card sending a final truncated descriptor therefore makes the kernel read whatever follows the descriptor: other stream bytes, then the uninitialized tail of the 1024-byte chunk (kmalloc without M_ZERO = kernel heap residue), and -- when the logical stream ends exactly at the chunk end, fully card-controlled because the card sizes the stream -- bytes PAST the heap allocation, or, at an allocation/page edge, unmapped KVA. FreeBSD head (sys/isa/pnpparse.c, checked 2026-10-18) carries the identical unguarded handlers, so this is inherited upstream behavior, not a DragonFly regression.

Bonus (same root cause, same fix): PNP_TAG_IO_RANGE contains a WRITE, if (res[5] == 0) res[5] = 1; (pnpparse.c:163-166) -- with len < 6 this is a 1-byte OOB write of 0x01 past the descriptor (conditional on the attacker-unknown adjacent bytes: res[6] != 0 and res[5] == 0).

Rig

Extends the PNPH verbatim-interposition kernel harness from the DF-2314/2315 run: this TU #includes the UNMODIFIED pnpparse.c (sha256-gated by prep.sh against the pristine audit tree, 4b13638c...), making the static pnp_parse_desc() callable; the stock pnpparse.c unit is dropped from conf/files; pnp.c stays the STOCK in-build unit. Scenarios driven through /dev/pnph0 (root-only) with real isa0 children as dev.

Evidence (run.log / fix_run.log / panic.txt)

1. Read set + worst case (scenario 20). Direct calls with marker bytes res[i] = i+1 and declared len 0: every parsed field equals the marker composition of offsets 0..N-1, all past a len-0 descriptor: MEM32_RANGE declen=0 need=17: TRUNCATED -- 17 bytes read past a len-0 descriptor (offsets 0..16) attrib=PASS, f[3]=0x11100f0e = I32(res+13) (markers 0x0e..0x11 at +13..+16). All 8 tags attributed; len=need controls PASS identically (attribution math is sound); a declared-16 MEM32_RANGE case shows the minimal 1-byte over-read.
2. Past the heap chunk (scenario 21). Descriptor at the end of a 512-byte kmalloc chunk, next adjacent chunk filled with the repeating text "DF2316CANARY!": stored ir_size=0x21595241 == I32(c2+9) ("ARY!"), ir_align=0x4e414336 == I32(c2+5) ("6CAN") -- kernel read canary bytes that live PAST the first chunk, 3/3 runs (leak_sample.txt).
3. Through the REAL entry point (scenario 23.2). A crafted card stream whose last descriptor (tag+len bytes at c1[1021..1023]) ends exactly at the end of a 1024-byte chunk, next chunk canary-filled, fed to the verbatim pnp_parse_resources(): stored config nmem=1, ir_size=0x33324644 == I32(c2+13) ("DF23") -- 17 canary bytes read fully past the allocation, same path a malicious card drives at boot.
4. Heap residue -> resource fields (scenario 23.3, the leak). A freed 1024-byte M_TEMP chunk (filled with "DF2316-RESIDUE-HEAPDATA-") is re-allocated as the card stream buffer (same address, same as the real pnp_read_bytes growth pattern); the truncated descriptor at its start makes the parser swallow the prior occupant remains: ir_size=0x44504145 == I32(st+16) (bytes "EAPD" of the residue). These values are stored via ISA_ADD_CONFIG into id_configs -- the data devinfo/bootverbose ("adding memory32 range ...") print for the device. Ceiling: ~17 bytes of adjacent kernel heap per truncated descriptor, attacker-repeatable within one stream (multiple descriptors) and across streams.
5. 1-byte OOB WRITE (scenario 22). IO_RANGE len 0 at a chunk end with the adjacent canary prepared (res+5 == 0x00, res+6 == 0x7F): canary byte 2 bytes past the chunk end flips 0x00 -> 0x01 (c2[0..7] before: cc cc 00 7f ... after: cc cc 01 7f ...), the pnpparse.c:163-166 res[5]=1 write landing outside its allocation.
6. Page-boundary fault -> panic (scenario 25, panic.txt). 3 pages kmem_allocd, the top 2 kmem_freed (their vm_map entries REMOVED -- the harness comment documents that a bare pmap_kremove is insufficient because trap_pfault (trap.c:855-878) lets vm_fault(kernel_map) re-materialize a PTE while the entry exists; observed live), descriptor payload in the last 13 bytes of page 1 so res+13..+16 lie on the entry-less page: baseline kernel takes Fatal trap 12: page fault while in kernel mode ... fault virtual address = 0xfffff80118371003 (= page2+3 = res+16, inside the I32(res+13) null-check read), supervisor read data, page not present, backtrace pnp_parse_desc()+0x685 <- run_pagebound(), panic: page fault, 551 MB crash dump written, guest wedged in the SMP reboot path. The control (scenario 26: same mapping, full len-17 descriptor inside page 1) parses normally -- the fault is specifically the truncation.

Fix validation (fix.diff, fix_build.log, fix_run.log)

fix.diff adds one guard per handler (smallest maintainer shape, mirroring the existing per-case "too many ..." guards) rejecting a declared length below the accessed width (4/2/1/7/3/9/17/9) with a single bogus <name> length %d line and skipping the descriptor. Applied to the guest tree (patch -p1, 8/8 hunks), kernel rebuilt and booted:

• scenario 20: all truncated attributions now FAIL (f[] = 0 -- nothing read or stored), len=need controls still PASS;
• scenario 21: ir_size=0, no canary bytes; scenario 22: canary byte stays 0x00 (not written); scenarios 23.1/2/3: stored configs nmem=0 -- no markers, no canaries, no residue;
• scenario 25: NO panic -- console shows bogus memory32 range length 0, parse returns, guest stays up (direct contrast with the baseline panic);
• scenario 24 (well-formed stream with all 8 tags at proper lengths): the 27-field stored-config vector is BIT-IDENTICAL baseline vs fixed (diff after CR-normalization: 27/27 match) -- no behavior change for conforming cards;
• scenario 26 control still PASS.

Privesc assessment (team directive: close explicitly)

No uid=0 path exists for this bug class:

• Reachability is boot-time only: the descriptor stream comes from the ISA PnP serial-isolation protocol (pnp.c:594-671, ports 0x279/0xa79 + READ_DATA) -- an attacker needs a malicious PHYSICAL ISA-PnP card or VM firmware (AV:P). No local unprivileged syscall, /dev node, or network path feeds these parsers; the rig needs root on an already-instrumented kernel.
• The primitive is a bounded READ (max 17 bytes, fixed offsets, one shot per descriptor) into device resource FIELDS (ir_start/ir_end/ir_size/ ir_align/irqmask/drqmask/compatid), observable as resource data (devinfo/dmesg) -- an info leak of adjacent heap contents, not a controlled copy into attacker-chosen kernel memory.
• The only WRITE is the fixed 0x01 byte at res+5 (pnpparse.c:165), conditional on unknown adjacent bytes; value and offset are not attacker-chosen, and the attacker cannot place the victim allocation.
• The panic variant is a crash (DoS), not control flow: the fault is a data-read on not-present, handled by trap_fatal.
• Escalation would require combining this with a separate heap-layout primitive and a victim consuming resource fields as pointers -- no such consumer exists (isa allocation treats them as integers).

Honest scope note: the demonstrated panic uses a rig-controlled mapping (entry-less page). In the stock pnp.c path the stream buffer is a kmalloc zone chunk whose neighbor is usually mapped, so the realistic boot-time manifestation is the leak/corruption side; the fault occurs when the buffer abuts unmapped KVA (e.g. at slab-region edges), which the card cannot place deterministically but which the kernel reaches under memory fragmentation. Both manifestations were reproduced from the same primitive; neither is a privesc.

Guest disposition

Baseline panic wedged the guest -> vm.sh reset with-src -> fix build/run -> final vm.sh reset with-src; guest returned clean (guest_dirty=0).

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.