DF-2323 — VPD cleanup NULL-sentinel walk after krealloc shrink — evidence pack

Finding: sys/bus/pci/pci.c:1225-1315 — the VPD error-cleanup loops scan vpd_ros/vpd_w for a NULL .value sentinel, but the success-path krealloc at pci.c:1225/1280 shrinks the arrays to exactly the live entry count, deleting the zero padding the sentinel scan relies on; a later error path walks and kfree()s past the allocation.

Verdict (short)

REPRODUCED (production-config kernel) — heap corruption: the verbatim pci_read_vpd walks the shrunk array past its end and kfree()s an attacker-influenced pointer; with a controlled neighbor chunk this is a free-of-LIVE-object (silent on production builds) followed by the same chunk being handed to a second owner (overlapping live kernel objects, demonstrated end-to-end); with a wild pointer it is a kernel page-fault panic. On the STOCK INVARIANTS kernel the walk is never reached: the shrink krealloc(..., M_ZERO) itself panics first (KKASSERT((flags & M_ZERO) == 0), kern_slaballoc.c:1187) — also captured. The finding's exact claimed trigger (bad checksum in a second VPD item) is REFUTED (fresh array + leak); the real co-trigger is the state < -1 I/O-error path. Fix A/B validated on both configs.

Rig

Established verbatim-interposition kernel-compiled harness (same class as the pnpparse/firewire/CAM rigs): rig/dfpci_pre.c (rename map + interposition) + sha256-gated VERBATIM extracts of the pci.c functions (rig/gen.sh, blob sha256 in env.txt) + rig/dfpci_post.c (fabricated pcicfg device: 256-byte config space, VPD addr/data register protocol with completion-bit stall point, BAR sizing readback; kmalloc/krealloc/kfree trackers that log and pass through to the REAL allocator; sysctl debug.dfpcih.cmd interface; hard-IRQ systimer watchdog used by the DF-2324 runs). The guest's real PCI stack keeps running untouched (harness TU is fully renamed).

Reproduce

1. sh rig/build.sh DFPCI — build+install the INVARIANTS rig kernel (then vm.sh up).
2. Baseline stock: sh rig/run_2323_stock.sh (sysctl debug.dfpcih.cmd="vpd errfirst" control stays alive; "vpd stock" panics at the krealloc M_ZERO assert — capture via dfbsd-qemu/vm.sh log 60 > panic_stock.txt).
3. Production config: rebuild with KERNCONF=DFPCIP (gen.sh creates it; INVARIANTS commented out), then sh rig/run_2323_prod.sh (natural x5 + badck2 + controls + groom).
4. Wild variant: sysctl debug.dfpcih.cmd="vpd wild" → page-fault panic (panic_wild.txt).
5. Fixed A/B: apply rig/fix.diff to the guest /usr/src (patch -p0), sh rig/gen_fixed.sh (re-extracts from the FIXED file, new sha256 gate), rebuild DFPCIPF and DFPCIF, re-run all scenarios (rig/fixed_runs.log).

Files

• VERDICT.md — full narrative + impact quantification
• panic_stock.txt — stock kernel: krealloc M_ZERO assert at pci.c:1225
• panic_wild.txt — production kernel: page fault in kfree(wild ptr)
• rig/groom.log — the corruption run (UNTRACKED kfree of live canary, kmalloc(64) == canary, TWO LIVE OWNERS SAME MEMORY)
• rig/natural_5runs.log — 5 natural runs + adjacency snapshots
• rig/badck2.log, rig/controls.log — claimed-trigger refutation + controls
• rig/fixed_runs.log — fixed-kernel A/B (0 untracked frees)
• rig/ — harness sources, generators, gates, run scripts, fix.diff
• env.txt — kernels, compiler, CFLAGS, verbatim hashes, reachability
• manifest.json, verdict.json

DF-2323 — VPD error-cleanup loops rely on a NULL sentinel that the success-path shrink krealloc removes — VERDICT

status: reproduced (on production-config kernel) / impact: corruption (free-of-live-object + overlapping allocations; wild-pointer variant panics; stock INVARIANTS kernel panics earlier at a krealloc KKASSERT in the same device-driven path).

Line-accurate analysis (verified mechanically)

• Success path: when a VPD-R item completes, pci.c:1223-1228 (fixed tree line numbers shifted +6) SHRINKS vpd_ros to exactly off entries via krealloc(..., off * sizeof(struct vpd_readonly), M_DEVBUF, M_WAITOK | M_ZERO) — 2 keywords => 128 -> 32 bytes. Every kept entry has a non-NULL .value, and the zero padding that used to act as the NULL sentinel is gone (krealloc 128->32 crosses size classes: kern_slaballoc.c krealloc allocates a fresh 32-byte chunk, bcopy(32), frees the 128-byte chunk). Same for vpd_w (pci.c:1278).
• Error path: pci.c:1297-1304 runs when cksumvalid == 0 || state < -1 and walks for (off = 0; cfg->vpd.vpd_ros[off].value; off++) kfree(...) — a NULL-sentinel scan with NO bound (pci.c:1300).
• Correction to the finding's exact trigger: a second VPD-R item with a bad checksum does NOT reach the shrunk array — case 0x10 (pci.c:1117-1124) unconditionally kmallocs a FRESH zeroed 8-entry array (replacing and LEAKING the shrunk one), so the cleanup walk stops at the fresh array's zero sentinel. Proven mechanically by the vpd badck2 run (rig/natural_5runs.log tail + badck2.log): bounded walk, no corruption, 3 leaked blocks (shrunk array + 2 keyword values).
• The real trigger is the I/O-error path: state < -1 (VPD register-read timeout, pci.c:1073-1076 -> pci_read_vpd_reg ENXIO after 1M completion polls) ALSO enters the same cleanup block, and it hits whatever vpd_ros currently is — including a successfully SHRUNK array whose entries are all non-NULL. The malicious device serves one well-formed VPD-R item, then stalls the VPD address register's completion bit.

What was run (all through the verbatim pci_read_vpd)

See README.md for build/run. Runs and logs:

Impact quantification on this kernel (team directive)

• Stock INVARIANTS kernel (as shipped in this dev tree): the claimed OOB-walk corruption is UNREACHABLE — every krealloc with M_ZERO (grow at pci.c:1150/1241, shrink at 1225/1280) panics FIRST with the KKASSERT. That is itself a device-triggerable kernel panic (any VPD-R item that completes, i.e. nearly every real VPD), but it is a different failure than claimed.
• Production-config kernel (INVARIANTS off — how release kernels build): the OOB walk is real. Natural runs stopped benignly only because the adjacent heap was zeroed at that moment; the groom run shows deterministic attacker influence over the freed pointer (device-controlled parse allocations and timing shape the 16/32/64 byte zones at enumeration). Consequences observed:
• kfree of a valid-looking LIVE object: SILENT — free lists corrupted, same chunk handed to a new owner while the old owner keeps it (overlapping live objects — classic exploitable slab corruption).
• kfree of a wild pointer: kernel page fault -> panic. Not caught by any zone check on a non-INVARIANTS build (chunk integrity checks are INVARIANTS-only in kern_slaballoc.c).
• Threat model: malicious PCIe device with a VPD capability (AV:P / crafted passthrough). The lazy pci_read_vpd caller set in-tree is small (vga_pci.c:544, if_age.c), but the parse runs with device data only.

Fix (validated A/B)

fix.diff (pack rig/fix.diff, hunks 4-11 of the combined diff): 1. Track the completed-entry count as entries complete (vpd_rocnt = ++off in state 3, vpd_wcnt in state 6) and reset the counts when a new VPD-R/VPD-W item starts (case 0x10/0x11). 2. Bound both error-cleanup loops by the count (for (off = 0; off < cfg->vpd.vpd_rocnt; off++)), matching the count-bounded convention already used by the device-teardown free path (pci.c:2146-2153) — the NULL-sentinel scan is then gone. 3. Drop M_ZERO from the four krealloc calls (krealloc does not support it — KKASSERT on INVARIANTS builds; and the sentinel is no longer needed once cleanups are count-bounded; when krealloc reallocates it passes flags through to _kmalloc which handles M_ZERO anyway, but the assert makes the flag unusable as shipped).

A/B: DFPCIPF (production+fix) — all scenarios re-run: 0 untracked frees, canary intact in the groom run, success/control semantics unchanged. DFPCIF (INVARIANTS+fix) — vpd stock no longer panics at the krealloc assert.

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)