DF-4738 — cbb_pci_attach(): collision-blind static CardBus bus-number allocator

File: sys/dev/pccard/pccbb/pccbb_pci.c (pass-2 GLM 5.3 re-audit)

Build (on the audit QEMU guest)

cc -Wall -Wextra -o /tmp/df4738 /tmp/df4738.c

Run

/tmp/df4738

Expected output (decisive lines)

=> COLLISION: two bridges now own bus 2; type-1 config
   cycles for the CardBus card are also claimed by pcie0 ...
socket #127: secbus_reg=256 -> u_int8_t secbus=0, ...
bugs: exit 0

Case 1 shows a firmware-configured PCIe root port keeping bus 2 while a cbb socket left unprogrammed (SECBUS=0) by firmware is renumbered onto the same bus 2 — the allocator never checks bus numbers already owned anywhere in the tree. Case 2 shows the shared static counter has no >255 bound: socket #127 draws secbus_reg=256, truncated into the u_int8_t softc field as 0 — the exact sentinel the driver itself treats as "unconfigured".

Why a userspace replica

The QEMU audit guest has no CardBus bridge (class 0x0607) PCI device at all — see guest_hw_evidence.txt — so cbb(4) never attaches and the in-kernel path cannot run. The renumbering arithmetic is deterministic, so a verbatim replica of pccbb_pci.c:299,344-359 with fixture bridges proves both defect axes.

DF-4738 VERDICT — collision-blind, unbounded static bus-number allocator in cbb_pci_attach()

Status: not_reproduced at runtime (hardware-gated — no CardBus bridge on the audit guest); allocator logic defect certain, demonstrated by a guest-run verbatim replica of the renumbering block; real-world manifestation requires a specific (but historically real) firmware state.

Root cause (path:line)

sys/dev/pccard/pccbb/pccbb_pci.c:299:

static int curr_bus_number = 2; /* XXX EVILE BAD (see below) */

and the renumbering block pccbb_pci.c:344-359:

pribus = pci_read_config(brdev, PCIR_PRIBUS_2, 1);
if (sc->secbus == 0 || sc->pribus != pribus) {
        if (curr_bus_number <= sc->pribus)
                curr_bus_number = sc->pribus + 1;
        ...
        sc->secbus = curr_bus_number++;
        sc->subbus = curr_bus_number++;
        pci_write_config(brdev, PCIR_SECBUS_2, sc->secbus, 1);
        pci_write_config(brdev, PCIR_SUBBUS_2, sc->subbus, 1);
}

Defect axes:

1. Collision-blind. When firmware leaves a CardBus socket unprogrammed (SECBUS == 0) — the state this block exists to handle — the socket is given curr_bus_number, which starts at 2 and is adjusted only for this bridge's primary bus (:346-347). Bus numbers that firmware already assigned to other bridges elsewhere in the tree (AGP/PCIe root ports routinely own bus 2..N) are never consulted. Two bridges then own the same bus number: type-1 config cycles intended for the CardBus card's bus are also claimed by the other bridge, so config reads/writes for a CardBus card can hit an unrelated real device — a card driver can program its BARs into, say, the display controller, or read the VGA controller's ID as the card's. Config-space corruption of unrelated devices (writable command register/BARs -> device DMA anywhere) is the worst-case fallout. (FreeBSD later rewrote this allocator; DragonFly still carries the 2005 code, as its own comment admits: "XXX EVILE BAD".)
2. Unbounded 8-bit space. curr_bus_number is an int with no <=255 check; sc->secbus/sc->subbus are u_int8_t (pccbbvar.h:68-69) and pci_write_config(..., 1) truncates to a byte. Socket #127 draws secbus_reg = 256 -> softc secbus = 0 — the very "unconfigured" sentinel :345 treats as invalid: re-renumbering on any re-probe/resume while cardbus children still reference bus 0 (= host bus). Subsequent sockets silently alias earlier bus numbers (mod 256).
3. Each socket unconditionally consumes two bus numbers (:353-354) even when one would do, accelerating exhaustion; and subbus is written before the guard-free increments, so a partial failure leaves config registers inconsistent.

Reachability: attach-time only, driven by PCI config state (firmware). No unprivileged-user trigger — this is a firmware/hardware-state defect on machines that actually have CardBus bridges (laptops of the yenta era).

Proof

cbb_busnum_alloc_demo.c replicates :299 and :344-359 verbatim (DEVPRINTF dropped) with fixture bridges; compiled with guest cc 8.3 and executed on the guest (run.log):

• Case 1 (firmware gave a PCIe root port bus 2; cbb socket SECBUS=0): cbb0 is renumbered to secbus=2 -> => COLLISION: two bridges now own bus 2.
• Case 2 (128 sockets): socket #127 -> secbus_reg=256 -> u_int8_t secbus=0; no >255 check exists.

Hardware gate: the audit guest's entire PCI inventory is i440FX/PIIX3/PIIX4-PM/virtio — no class 0x0607 (CardBus) device (guest_hw_evidence.txt). cbb(4) is compiled into the kernel but never attaches, so the in-kernel path cannot execute; hence not_reproduced with certain allocator logic.

Fix

Minimal guard (fix.diff): fail attach (goto err) when curr_bus_number > 254 instead of truncating into the u_int8_t fields. The collision axis needs the real fix: allocate secondary bus numbers centrally (walk the already-enumerated tree for the highest assigned bus, or delegate to the PCI core's bus-number allocation, as FreeBSD's later pccbb rework does) rather than a driver-static counter seeded at 2.

Fix validation

Not testable on this guest (no CardBus bridge; a single-fix kernel build has no CardBus attach to observe). The guard's arithmetic (254+1 = 255 max) and the truncation semantics are exercised by the demo's case 2.

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.