β¬’ DragonFlyBSD Kernel Audit
← triage Β· dashboard
DF-2306

Unconditional PCI vendor/device ID disclosure to console in probe routine

Summary

The generic-class fallthrough in fwohci_pci_probe unconditionally prints PCI vendor and device IDs to system console via device_printf without any bootverbose or firewire_debug guard. Inconsistent with specific-ID matches above (which only call device_set_desc) and leaks hardware identifying information on every boot for any OHCI-1394 controller not in hard-coded list. Hardening/info-disclosure issue. [VERIFIED pass2: reproduced - real probe on fabricated generic-class identity prints vendor/device IDs unguarded; bootverbose fix-validated - silent at 0, prints at 1]

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-2306 Β· 18 files
FileTypeDescriptionSize
fwpci_harness.c β€” 23.5 KB view raw
fwpci_harness.h β€” 1.8 KB view raw
fwohci_harness.c β€” 22.3 KB view raw
fwohci_harness.h β€” 3.9 KB view raw
fwpcictl.c β€” 3.6 KB view raw
fwpci_prep.sh β€” 1.9 KB view raw
build_kernel.sh β€” 358 B view raw
build_fix.sh β€” 519 B view raw
run.sh β€” 117 B view raw
run.log β€” 725 B view raw
run_fixed.log β€” 2.1 KB view raw
fix.diff β€” 896 B view raw
env.txt β€” 1.4 KB view raw
build.log β€” 2.0 KB view raw
README.md β€” 1.8 KB ↓ raw
VERDICT.md β€” 2.4 KB ↓ raw
manifest.json β€” 1.1 KB view raw
verdict.json β€” 2.7 KB view raw

DF-2306 β€” Unconditional PCI vendor/device ID console disclosure in probe

Verification pack for finding DF-2306 (sys/bus/firewire/fwohci_pci.c:190-191). Info / kernleak. Claim: the generic-class fallthrough in fwohci_pci_probe prints the PCI vendor and device IDs to the console with device_printf unconditionally β€” no bootverbose/firewire_debug guard β€” for every 1394-OHCI controller not in the hard-coded ID table.

Verdict (short)

REPRODUCED line-accurately and mechanically: the REAL fwohci_pci_probe (verbatim TU rig) invoked with a fabricated PCI identity of class=0x0c/0x00/progif=0x10 (generic 1394 OHCI) and vendor/device (0x1a2b/0x3c4d) NOT in the table, fell through to the class match and printed fwohci6: vendor=1a2b, dev=3c4d to the console, set the description, and returned 0. On real hardware this line appears on every boot for any OHCI controller absent from the ID table (the table has 25 entries; plenty of controllers, e.g. many TI/NEC/Lucent revs and all newer chips, fall through). Info-severity: PCI IDs are semi-public hardware identifiers, but they do fingerprint the exact controller and the print is unconditional boot noise; the specific-ID matches above print nothing.

Files

Same rig as DF-2304 (shared verbatim-interposition harness): * fwpci_harness.c/h, fwohci_harness.c/h, fwpcictl.c β€” rig * run.sh β€” fwpcictl probe 0x1a2b 0x3c4d 0x0c 0x00 0x10 + dmesg check * run.log β€” baseline console output (the disclosure line) * run_fixed.log β€” fixed kernel: silent at bootverbose=0, prints at 1 * fix.diff β€” combined 3-hunk fix (hunk 1 guards the print)

Reproduce

scp -F dfbsd-qemu/config * dfbsd:/root/fwo/
vm.sh run_root 'sh /root/fwo/fwpci_prep.sh && sh /root/fwo/build_kernel.sh'
vm.sh down && vm.sh up
vm.sh run_root 'sh /root/fwo/run.sh'      # dmesg shows: fwohci6: vendor=1a2b, dev=3c4d
VERDICT.md
↓ download raw

DF-2306 VERDICT β€” unconditional vendor/device ID print in probe fallthrough

  • finding: DF-2306, fwohci_pci.c:190-191 (fwohci_pci_probe)
  • status: reproduced (the exact print behavior demonstrated through the verbatim probe function)
  • impact: leak (hardware-identifying console disclosure; Info severity β€” PCI IDs are enumerable by other means by anyone with local access to the bus, but the print is unconditional and unguarded)
  • confidence: certain

Line-accurate analysis

fwohci_pci.c:187-194: after the 25-entry hard-coded ID table fails to match, the generic class check pci_get_class==PCIC_SERIALBUS && subclass==PCIS_SERIALBUS_FW && progif==PCI_INTERFACE_OHCI executes device_printf(dev, "vendor=%x, dev=%x\n", pci_get_vendor(dev), pci_get_device(dev)); with NO guard β€” then sets the description and returns 0. Every specific-ID match above prints nothing. The driver has no other probe-time print. Sibling style in the same file: probe-time / attach-time noise elsewhere is guarded by if (bootverbose) (fwohci_pci.c:261-262) or if (firewire_debug) (fwohci_pci.c:238).

Mechanical reproduction (this run)

fwpcictl probe 0x1a2b 0x3c4d 0x0c 0x00 0x10 drives the REAL fwohci_pci_probe on the rig shell (parent = fabricated pci bus kobj serving BUS_READ_IVAR). Console/dmesg:

FWP: PROBE vendor=1a2b device=3c4d class=0c subclass=00 progif=10 -> REAL fwohci_pci_probe(0xffffffff817b14c0)
fwohci6: vendor=1a2b, dev=3c4d
FWP: PROBE returned 0 desc="1394 Open Host Controller Interface"

The disclosure line is emitted by the stock code path; rc=0 and the description are set as in a real boot. (No 1394 hardware exists on the guest β€” the print targets the fabricated identity; the code path is byte-identical to what a fall-through controller hits at every boot.)

Fix validation (A/B)

fix.diff hunk 1 wraps the print in if (bootverbose) (sibling style). Fixed kernel (run_fixed.log): * bootverbose=0 -> probe returns 0, description set, NO console line. * bootverbose=1 (rig sets the kernel variable) -> the line prints. Baseline vs fixed: unconditional print vs bootverbose-gated.

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.

Fix verification

not_testable
↓ fix.diffper-fix-DF-2306

Confirmed kernel references

Detail

Evidence (decisive lines)

run.log: dmesg shows FWP: PROBE ... -> REAL fwohci_pci_probe followed by the stock console line fwohci6: vendor=1a2b, dev=3c4d and FWP: PROBE returned 0 desc=1394 Open Host Controller Interface. run_fixed.log: at bootverbose=0 no vendor line between the markers; at bootverbose=1 the line prints.

PoC changes

Built on the new fwpci_harness.c rig (shared with DF-2304): fabricated PCI identity via the pci bus kobj BUS_READ_IVAR emulation, direct call of the verbatim static probe, plus a bootverbose toggle ioctl for the A/B.

Verified recommended fix

Guard the device_printf at fwohci_pci.c:190 with if (bootverbose), matching the style at :261-262.

Verdict

The REAL fwohci_pci_probe (verbatim TU rig) invoked with a fabricated generic-class 1394 OHCI identity (class 0x0c, subclass 0x00, progif 0x10, vendor/device 0x1a2b/0x3c4d not in the 25-entry hard-coded table) fell through to the class match at fwohci_pci.c:187-194 and unconditionally printed fwohci6: vendor=1a2b, dev=3c4d to the console via the unguarded device_printf at fwohci_pci.c:190-191, then set the description and returned 0. On real hardware this line is emitted on every boot for any OHCI controller absent from the ID table. Info severity confirmed: it discloses only semi-public hardware identifiers, but unconditionally and inconsistently with the specific-ID matches (which print nothing) and with the bootverbose/firewire_debug guards used elsewhere in the file (:261, :238). Fixed by hunk 1 of fix.diff (if (bootverbose) guard, sibling style); A/B validated on the fixed kernel: silent at bootverbose=0, prints at bootverbose=1, probe rc and description unchanged.