DF-5598 — ichsmb detach-veto family residue (Info, hardening)

File: sys/bus/smbus/ichsmb/ichsmb_pci.c (pass 2) Class: detach-veto family (DF-5544 / DF-5545 / DF-5562 / DF-5528 / DF-4558) — mitigated variant

What this pack demonstrates

ichsmb_pci.c:175 wires device_detach to ichsmb_detach() (ichsmb.c:680), whose device_delete_child(dev, sc->smb) return at ichsmb.c:689 is ignored before the unconditional ichsmb_release_resources() + lockuninit() + return 0. This is the family shape — but unlike uhci/xhci/ohci, ichsmb_detach first runs a checked bus_generic_detach(dev) cascade (ichsmb.c:686) and smbus_detach() checks its own cascade (smbus.c:110-112).

This harness attaches a vetoing child (EBUSY) directly under smbus0 (grandchild of ichsmb0) and drives the exact kldunload path (linker_file_unload -> devclass_delete_driver, subr_bus.c:897).

Build (inside the guest)

sh build.sh        # make KERNBUILDDIR=/usr/obj/usr/src/sys/X86_64_GENERIC

Requires: q35 rig guest (-machine q35 -device ipmi-bmc-sim,id=bmc0 -device smbus-ipmi,bmc=bmc0,address=0x20 -device i2c-ddc,address=0x50), kldload ichsmb, kldload smb.

Run (as root, inside the guest)

sh run.sh

Expected output

• kldunload ichsmb fails (Device busy) while the veto child is armed: df5598veto0: DETACH VETO: returning EBUSY on the console, and devinfo -r still shows ichsmb0 with I/O ports 0x700-0x73f and irq 16 — the veto is HONORED, nothing is torn down, no panic. (This is the opposite of DF-5544, where the same trigger produced uhci0: detached + return 0 + freed softc + fatal page fault.)
• Collateral observed: smb0/smb1 are detached (their /dev/smb* nodes removed) before the veto surfaces — a vetoed unload leaves the SMBus service dead until a successful retry (generic newbus non-transactional detach; robustness note, not memory corruption).
• After sysctl hw.df5598_armed=0, kldunload ichsmb returns 0 and the whole subtree (df5598veto0, smbus0, ichsmb0) detaches cleanly.

Artifacts

• veto.c, Makefile — the KLD stand-in veto child (adapted from the DF-5544 harness; the kernel thread is unnecessary because kldunload is a stock syscall-level trigger here).
• build.sh, build.log — build transcript.
• run.sh, run.log — full decisive run.
• fix.diff — check + propagate device_delete_child() (hardening).
• env.txt, VERDICT.md, manifest.json, verdict.json.

DF-5598 VERDICT — detach-veto family residue on ichsmb: NOT the uhci bug

Bottom line

not_reproduced / impact none / certain. The DF-5544/5545/5562 family failure (deterministic teardown-under-veto) does not manifest on the ichsmb PCI glue: every deterministic veto in the subtree is caught one level up by the checked bus_generic_detach() cascade, so ichsmb_release_resources() never runs under a vetoing child. The ignored device_delete_child() return at ichsmb.c:689 (reached via the DEVMETHOD(device_detach, ichsmb_detach) wiring at ichsmb_pci.c:175) is a genuine newbus-contract violation and is kept as an Info defense-in-depth finding consistent with the family sweep.

Why the family bug is unreachable here (code)

1. ichsmb_detach (ichsmb.c:686-688) checks bus_generic_detach(dev) and returns the error before any teardown. bus_generic_detach (subr_bus.c:2867-2880) detaches all children, cascading.
2. The only child is smbus0 (ichsmb.c:114); its smbus_detach (smbus.c:106-115) checks its own bus_generic_detach over the smb0..smbN (and any other) children.
3. The in-tree leaf smb_detach (smb.c:147-155) never vetoes — it removes the devfs node and returns 0 unconditionally, even with /dev/smbN open (mode 0600 root anyway).
4. After a successful bus_generic_detach, the second-phase device_detach(child) inside device_delete_child (subr_bus.c:1292) is a no-op (state != DS_ATTACHED -> return 0, subr_bus.c:2136-2137), so no in-tree veto can surface there.
5. The DS_BUSY early-EBUSY (subr_bus.c:2134-2135) requires device_busy() on an smbus-subtree device; the only callers in the tree are cxm/bktr/agp/drm/fd — none in sys/bus/smbus or sys/dev/smbus.

Residual exposure of the unchecked call (ichsmb.c:689): * a driver kldloaded onto the smbus bus concurrently with the kldunload (root-vs-root race) that attaches a child between the checked generic detach and device_delete_child — its veto would then be swallowed and ichsmb_release_resources() + lockuninit() would run under it while device_detach(ichsmb0) reports success; * any future smbus-bus driver whose detach vetoes only in the second phase (none possible today, per 4).

Live evidence (q35 + ipmi-bmc-sim rig, ICH9 82801I at 0:31:3)

run.log — decisive run:

kldunload ichsmb -> "kldunload: can't unload file: Device busy" (rc=1)
df5598veto0: DETACH VETO: returning EBUSY ...
>>> ichsmb0 still attached with resources: veto HONORED
  ichsmb0 / Interrupt request lines cpu4: 16 / I/O ports 0x700-0x73f   (intact)
sysctl hw.df5598_armed=0
kldunload ichsmb -> rc=0, df5598veto0/smbus0/ichsmb0 detach cleanly

Serial (dmesg) confirms the unwind order: smb1: detached -> smb0: detached -> df5598veto0: DETACH VETO -> (unload aborts, resources intact), then after disarming: df5598veto0: cooperating -> detached -> smbus0: detached -> ichsmb0: detached.

Contrast with DF-5544 (same harness pattern, uhci): there the trigger yielded uhci0: detached, return 0, freed softc and a Fatal trap 12 page fault. Here: honest EBUSY, zero teardown, guest healthy.

Observed collateral (noted, not filed)

The vetoed unwind still detaches smb0/smb1 before the veto surfaces (their /dev/smb* devfs nodes are destroyed — verified by the failed smbmsg checks in run.log), so a vetoed kldunload ichsmb leaves the SMBus userland interface dead until a successful retry, even though the controller keeps its IRQ/IO. This is generic newbus non-transactional detach semantics (the same "retry later" posture DF-5544's fix embraces), not a memory-safety defect, and it is not re-filed separately.

Fix

fix.diff — propagate device_delete_child()'s error before touching resources (3 lines, mirrors the family fix). Not kernel-rebuild-validated: there is no reproducible bad behavior to A/B on this rig (that is the point of the finding), so fix_status=not_testable; the diff is trivially reviewable and matches the validated DF-5544/5545/5562 fix shape.

Negative results recorded during this pass (pass-2 depth)

• Probe table walk bounded/NULL-terminated (ichsmb_pci.c:210-215); duplicate ICH7/8/9 rows (:121-126) are cosmetic first-match-wins.
• No revision/quirk dispatch exists (checklist item c): DID-only match at ichsmb_pci.c:211 — nothing attacker-shaped to reach.
• ICH_HOSTC byte write at ichsmb_pci.c:255 clobbers SMB_SMI_EN / I2C_EN (ichsmb_reg.h:53-56) — firmware-config destruction only; no attacker control, no kernel-memory consequence. It also happens before bus_setup_intr (ichsmb.c:124), but no SMBus transaction source is armed before smbus_attach's probing (smbus.c:94-100) which runs after the handler install — window benign. HOSTC is neither restored on attach failure nor disabled on detach (no shutdown method, ichsmb_pci.c:171-193): controller left HST_EN with IRQ released after unload — real-HW robustness smell (unhandled SMBALERT# level IRQ), Info-grade, recorded here rather than filed.
• Attach error unwinding at the PCI level (ichsmb_pci.c:258-266) is sound; the deeper ichsmb_attach unwinding bugs are DF-5460's (not re-reported).
• RF_SHAREABLE IRQ (ichsmb_pci.c:246-247) with a spurious-safe handler (ichsmb.c:509-518) — OK.
• No copyin/copyout, no lengths, no locks in this file.
• bus_generic_detach's TAILQ_FOREACH vs concurrent device_add_child (subr_bus.c:2875) — generic newbus root-vs-root race, not file-specific.

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.