DF-5510 -- OOB stack read + cross-field misclassification in ppb_pnp_detect() class search (search_token(class, len))

What

ppbconf.c:278 passes the interior pointer class' with the ABSOLUTE device-ID lengthlen' to search_token(); the scan runs up to (class-str) bytes past the 257-byte stack object str[PPB_PnP_STRING_SIZE+1], and even in-bounds it scans across the following PnP fields instead of stopping at the class field's end.

Build / run / expected (inside the DragonFly guest)

build (guest): sh build.sh     # compiles VERBATIM /usr/src/sys/bus/ppbus/ppbconf.c + ppb_1284.c + ppb_base.c into ppbharness2.ko
run   (guest): sh run.sh       # kldload; sleep 75; dmesg | grep PPBX2
expected pristine: "DF-5510 Ta ... class_id=0 (PRINTER)" (deterministic cross-field misclassification of class value 'QQ')
                  "DF-5510 Tb OOB result: class_id=1 (MODEM)"  (token matched in bytes past the str[] object; dirt map shows MODEM@-164)
                  "DF-5510 Tc control ... class_id=10 (UNKNOWN)" (in-bounds control with identical dirt)
expected patched: Ta=10 UNKNOWN, Tb=10 UNKNOWN, Tc=10 UNKNOWN

Rig

ppbharness2.ko compiles the VERBATIM production sources /usr/src/sys/bus/ppbus/{ppbconf.c,ppb_1284.c,ppb_base.c}; a fake "ppc" controller on nexus provides a fully scripted (malicious) IEEE1284 peer. Details in VERDICT.md; shared rig sources in the DF-5510 pack (identical copies here).

DF-5510 VERDICT

OOB stack read + cross-field misclassification in ppb_pnp_detect() class search (search_token(class, len))

REPRODUCED (rig) 4/4 fresh-boot runs

• Evidence class: no parallel port exists in QEMU, so the rig compiles the UNMODIFIED production ppbconf.c (sha256 c853ab25...) into a KLD together with ppb_1284.c and ppb_base.c, and drives it through a fake "ppc" chipset driver on nexus. ppbconf.c's own DRIVER_MODULE(ppbus, ppc, ...) attaches the real ppbus driver, so ppbus_attach -> ppb_scan_bus -> ppb_pnp_detect -> search_token all run production code; the fake peer hands ppb_1284_read_id() an attacker-chosen 256-byte IEEE1284 device ID nibble by nibble (receipt: the 'ppb: 256 characters: A(0x41)...' line in run4.dmesg shows the exact crafted bytes arriving).

• Ta (deterministic, in-bounds): ID "CLS:QQ;CMD:PRINTER;" -> class value is "QQ" but search_token(class=str+4, len=19, "PRINTER") scans the whole remainder of the string, finds PRINTER inside the CMD field, and class_id becomes 0 (PRINTER). 4/4 runs. Correct answer: 10 (UNKNOWN).

• Tb (OOB past the object): 256-byte ID, "CLS:" at offset 248 -> class = str+252; search_token(class, 256, tok) scans str[252..507], i.e. 251 bytes past the end of the 257-byte str[] object. The stack below the attach chain is pre-dirtied with class tokens; in all four runs the scan matched MODEM in out-of-bounds bytes (class_id=1) -- the dirt map confirms MODEM surviving at -164 bytes below the worker frame, exactly the region the OOB scan covers. A 5-byte-or-longer token match cannot be explained by the single uninitialized in-object byte str[256]; it requires reading >=4 bytes past the object.

• Tc (control): identical dirt, short ID -> the clamped-by-data scan stays inside str[] -> UNKNOWN 4/4. Proves the dirt alone cannot flip the result; only the wrong `len' argument does.

Impact ceiling: silent OOB kernel-stack READ at ppbus attach, driven by peripheral-supplied bytes; ppb->class_id has no readers in-tree, so no exfiltration path, no write primitive, no panic observed (kernel stacks are contiguous and mapped). Hardware-gated (crafted IEEE1284 peripheral). NOT the same defect as DF-2328 (UNKNOWN_LENGTH scan of a non-NUL-terminated buffer) -- Tb's buffer is fully terminated; the OOB here comes from the length argument alone.

FIX VALIDATED: with the scan clamped to the class field (fix.diff hunk 1), Ta and Tb return UNKNOWN on two fresh patched boots (fixrun1/fixrun2).

-- status=reproduced reproduced=True impact=none confidence=certain fix_status=fixed (baseline reproduced, patched behavior gone)

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.