DF-5454 — PCIe MMIO config backend: missing reg+width bound → OOB access past pcie_base devmap

File under audit (pass 2): sys/bus/pci/x86_64/pci_bus.c Sink: sys/bus/pci/x86_64/pci_cfgreg.c (pciereg_cfgread/pciereg_cfgwrite)

What

The legacy host-PCI bridge config bridges legacy_pcib_read_config / legacy_pcib_write_config (pci_bus.c:61-75) forward caller-supplied (bus, slot, func, reg, bytes) to pci_cfgregread/pci_cfgregwrite with no validation. When MMIO config space is active (CFGMECH_PCIE — Intel 7520/7320/915/925/915GM chipsets, pci_cfgreg.c:104-124, or any ACPI MCFG table, sys/dev/acpica/acpi.c:1669), the request lands in pciereg_cfgread/pciereg_cfgwrite (pci_cfgreg.c:315-365), which bound-check only reg > PCIE_REGMAX (4095). They never check reg + bytes <= 4096 and never check alignment — both of which the port-I/O backend pci_cfgenable (pci_cfgreg.c:187-193) enforces.

The MMCFG window is pmap_mapdev_uncacheable(base, (maxbus+1) << 20) (pci_cfgreg.c:278-279) — with maxbus=255 a 256MB kernel_map allocation. The highest mapped byte is (bus=255, slot=31, func=7, reg=0xfff). A 2-byte access at reg=0xfff or 4-byte access at reg=0xffd/0xffe reads/writes 1-3 bytes past the end of that kernel virtual allocation → kernel page fault (panic) or silent corruption of the adjacent kernel mapping.

Reachability / threat model

• /dev/pci PCIOCREAD/PCIOCWRITE (pci_user.c:602-673) checks pi_width in {1,2,4}, pi_reg >= 0, alignment — but sets no upper bound on pi_reg — then calls PCIB_READ_CONFIG/PCIB_WRITE_CONFIG → these bridges. Opening /dev/pci requires SYSCAP_RESTRICTEDROOT (pci_user.c:82) → root-only.
• Kernel-internal callers keep reg <= 0xff (capability walk clamps/aligns via pci_fixup_nextptr, pci.c:602-630). No in-tree caller passes reg>0xff except the ioctl.
• Requires CFGMECH_PCIE — dormant on QEMU i440FX (no MCFG; host bridge 8086:1237 not in the chipset list), active on most modern MCFG-bearing x86_64 hardware and on the listed Intel chipsets.

Net: privileged-user-triggerable kernel OOB read/write (1-3 bytes) past a kernel_map devmap allocation → reliable panic (DoS), potential corruption of the adjacent kernel mapping. Severity: Low (already-privileged attacker).

Reproduce (this pack)

1. build.sh — compile the KLD inside the guest (needs /usr/src, cc, make).
2. run.sh — kldload /root/df5454/df5454.ko as root.

The KLD performs the exact legal pcie_cfgregopen() call the platform/ACPI makes at boot (activating CFGMECH_PCIE — dormant on the i440FX guest), then:

• CONTROL: in-bounds read (255,31,7,0xffc,4) — succeeds, no fault.
• step2: OOB read (255,31,7,0xfff,2) — Fatal trap 12, supervisor read, page not present, fault VA exactly pcie_base + 0x10000000.
• step3/4: OOB write / 3-bytes-past read (only reached if step2 survives).

Expected (vulnerable kernel): panic at step2 — see panic.txt. Expected (patched kernel, fix.diff): no panic; step2 returns 0xffffffff (rejected), module load completes, guest stays up — see run_patched.log.

Fix

fix.diff — carry the mech-1 backend's width/alignment/end bound into pciereg_cfgread/pciereg_cfgwrite. Validated: baseline panics, patched kernel rejects the access and boots/runs normally.

DF-5454 — VERDICT

Finding: legacy_pcib_read_config/legacy_pcib_write_config (sys/bus/pci/x86_64/pci_bus.c:61-75) forward caller-supplied (reg, bytes) into pci_cfgregread/pci_cfgregwrite with no validation; when MMIO config space is active (CFGMECH_PCIE), the backend pciereg_cfgread/ pciereg_cfgwrite (sys/bus/pci/x86_64/pci_cfgreg.c:315-365) bound-checks only reg > PCIE_REGMAX (4095) — it never checks reg + bytes <= 4096 nor alignment, both of which the port-I/O backend pci_cfgenable (pci_cfgreg.c:187-193) enforces. The MMCFG window is a pmap_mapdev_uncacheable(base, (maxbus+1)<<20) kernel_map allocation (pci_cfgreg.c:278-279; pmap.c:6174-6217 kmem_alloc_nofault); its highest mapped byte is (bus=255, slot=31, func=7, reg=0xfff). A width-2 access at reg=0xfff (or width-4 at reg=0xffd/0xffe) reads/writes 1-3 bytes past the end of that allocation.

Reproduced — how

1. Baseline (vulnerable kernel, snapshot with-src, kernel #0 Jul 2 2026): - KLD df5454.ko (this pack) performs the exact legal call a platform makes at boot to activate MMIO config — pcie_cfgregopen(0x40000000, 0, 255), the same call ACPI MCFG handling makes at sys/dev/acpica/acpi.c:1669 (the QEMU i440FX guest has no MCFG and an unlisted host bridge 8086:1237, so the backend is dormant on stock boot; the KLD removes that environmental precondition only). - CONTROL: in-bounds read (255,31,7,0xffc,4) — succeeds (0x00000000), proving the mapping is healthy up to its final byte. - OOB: read (255,31,7,0xfff,2) → Fatal trap 12: page fault while in kernel mode, supervisor read data, page not present, fault VA 0xfffff80128660000 = pcie_base + 0x10000000 exactly (mapping base 0xfffff80118660000), stopped at pci_docfgregread+0xb4: movzwl (%rax),%eax — the inlined *(volatile uint16_t *) load of pciereg_cfgread (see panic.txt, run.log). - Guest wedged in DDB; ssh never returned (rc 124). That is reproduced, impact panic, from a root-triggered KLD.

2. Patched (fix.diff applied, nativekernel build, kernel #1 Oct 5 18:56): - Same KLD, same commands: CONTROL read still OK (0x0000000b), OOB read at 0xfff/2 rejected → returns 0xffffffff, OOB write rejected (no-op), 0xffd/4 rejected, KLDLOAD_RC=0, guest stayed up (see run_patched.log). Bad behavior GONE → fix validated.

Why root-gated (severity Low, not higher)

• The only caller that supplies attacker-chosen reg is /dev/pci PCIOCREAD/PCIOCWRITE (sys/bus/pci/pci_user.c:602-673): it validates width∈{1,2,4}, pi_reg >= 0 and alignment, but sets no upper bound on pi_reg — however opening /dev/pci requires caps_priv_check_self(SYSCAP_RESTRICTEDROOT) (pci_user.c:82), i.e. root.
• All kernel-internal callers keep reg <= 0xff aligned (capability walk: pci_fixup_nextptr, sys/bus/pci/pci.c:602-630).
• Activation requires CFGMECH_PCIE (Intel 7520/7320/915/925/915GM chipsets at pci_cfgreg.c:108-123, or ACPI MCFG at sys/dev/acpica/acpi.c:1669) — i.e. most modern MCFG-bearing hardware, dormant on QEMU i440FX.

An already-privileged user gets: reliable kernel panic (DoS) and a 1-3 byte OOB write primitive into whatever kernel mapping follows the MMCFG window in kernel_map — corruption, not controllable enough for privilege escalation beyond what the trigger already requires. No unprivileged chain exists (open of /dev/pci is capability-gated). uid=0 escalation: not applicable (trigger requires root).

Conclusion

Real, proven missing-bounds defect in the x86_64 PCI config path — filed against sys/bus/pci/x86_64/pci_bus.c (the unvalidated pass-through bridges are this file's code; the sink and the fix live in the sibling backend pci_cfgreg.c, which pass 1 marked clean). Severity Low (privileged trigger), confidence certain, reproduced as panic, fix validated end-to-end (build + boot + re-run).

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.