DF-5521 — iicsmb detach has no quiesce: kldunload during an in-flight SMBus transaction executes freed module text (UAF) and leaves iicbus_softc->owner dangling

What this is

Evidence pack for the pass-2 finding against sys/bus/iicbus/iicsmb.c (the I2C-to-SMBus bridge). Verified on the QEMU guest with a software I2C controller KLD so that the production module chain

isa -> dfa_iic0 -> iicbus0 -> iicsmb0 -> smbus0 -> smb0 (/dev/smb0)

runs entirely on stock/production code paths (only the wire is software).

Files

df5521_rig.c software iicbus controller (isa child, wire-logged, configurable READ sleep = in-flight window, sysctl to inject iicbus_intr events like a real controller ISR) df5521_poc.c userland PoC (root): proto / groom / race / racefixed / fireevent modes against /dev/smb0 build.sh exact guest build commands load_chain.sh module load order bringing the chain up run.sh baseline reproduction (expects panic) panic.txt captured serial-console panic (freed-text execution) run.log baseline session transcript excerpts run.fixed.log fix-validation transcript (EBUSY + clean unload + alive) fix.diff validated fix (iiconf.c accessor + iicsmb.c guard + smbus.c guard) build.log decisive compiler/link lines (guest, -Werror, clean) env.txt guest uname / kldstat / toolchain manifest.json machine-readable catalog verdict.json machine verdict (persist_poc.py schema)

Reproduce (baseline)

1. vm.sh reset with-src, vm.sh up
2. push df5521_rig.c df5521_poc.c to guest /root
3. guest: sh /root/build.sh (see build.sh)
4. guest: sh /root/load_chain.sh
5. guest: sysctl hw.dfa.rdelay=300
6. guest: /root/df5521_poc race
7. EXPECT: smb0: detached / smbus0: detached / iicsmb0: detached, then the sleeping child wakes and the console shows Fatal trap 12: page fault ... fault virtual address = 0xffffffff8261f0bf (inside the unloaded iicsmb.ko text range) -> DDB db> prompt.

Reproduce (fix validation)

Apply fix.diff inside the guest's /usr/src, rebuild iicbus.ko + iicsmb.ko and (because smbus is compiled into X86_64_GENERIC) the kernel (make nativekernel && make installkernel, reboot), then:

kldload iicbus && kldload iicsmb && kldload smb && kldload df5521_rig.ko
sysctl hw.dfa.rdelay=300
/root/df5521_poc racefixed

EXPECT: kldunload: can't unload file: Device busy while the child is mid-BREAD, child continues unharmed, and after the client stops the unload succeeds; guest alive.

DF-5521 VERDICT — REPRODUCED (kernel UAF / freed-module-text execution; fix validated)

The bug

iicsmb_detach() (sys/bus/iicbus/iicsmb.c:164-175) has no quiesce of any kind: no busy count, no drain, no check whether the bridge currently owns the underlying iicbus, and it ignores bus_generic_detach()'s error before unconditionally deleting its smbus child. An SMBus client transaction routed through the bridge (every /dev/smb0 ioctl, every ipmi_ssif request, every kernel smbus client) holds the iicbus for the whole transaction (smbioctl -> smbus_request_bus -> iicsmb_callback -> iicbus_request_bus(parent, iicsmb0) sets iicbus_softc->owner, smb.c:240-243,356) and can be asleep inside iicbus_read()/iicbus_write() (controller polling / bit-bang delays) below the bridge.

devclass_delete_driver() (sys/kern/subr_bus.c:853-899) force-calls device_detach() for every device of the driver and, on success, the kldunload completes and frees the module text. Because iicsmb.ko also registers the smbus driver on the iicsmb bus (iicsmb.c:510, DRIVER_MODULE(smbus, iicsmb, ...)), unloading iicsmb.ko force-detaches smbus0/smb0 through that registration without ever calling iicsmb_detach — so even a guard in iicsmb_detach alone does not close the window (verified: two crashes through exactly that path during fix development).

Reproduction (baseline, stock modules)

Rig: software iicbus controller on isa (df5521_rig.c) -> production chain iicbus0/iicsmb0/smbus0/smb0 with /dev/smb0 (0600 root). hw.dfa.rdelay=300 makes the controller's READ sleep 300 ms so a BREAD ioctl is observably in flight. PoC race: child loops SMB_BREAD; parent kldunload mid-transaction. Captured serial (panic.txt):

READ req_len=255  <== bridge *count
smb0: detached
smbus0: detached
iicsmb0: detached
df5521-wire: READ gave 255 bytes: 08 a0 a1 a2 ...
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xffffffff8261f0bf
fault code              = supervisor read instruction, page not present
current process         = 989
Stopped at      iicbus_devclass+0x1e3e7:

The faulting address 0xffffffff8261f0bf lies inside iicsmb.ko's unloaded text range (kldstat before the unload: iicsmb.ko at 0xffffffff8261f000, size 0xe000): the thread that was asleep in the controller read resumed executing freed module code after kldunload iicsmb completed. A second crash mode (observed twice during fix development, same race): the woken sleeper returns into iicsmb_bread, then smbioctl calls smbus_release_bus() on the already-freed smbus0 device -> Fatal trap 12 ... fault virtual address = 0x0 ... Stopped at smbus_release_bus+0x78.

Additionally, after any successful unload iicbus_softc->owner keeps pointing at the orphaned iicsmb0 device whose driver was unhooked, so the next iicbus_intr() dispatches through a driverless kobj (iiconf.c:50-51).

Threat model

Triggering requires root (open /dev/smb0 0600 + kldunload, or root's kernel clients racing an admin unload — e.g. ipmi_ssif transactions from /dev/ipmi0 or the SSIF poller). It is a genuine kernel UAF (execution of freed text + freed-device dereference) but privileged-only: severity Low, family-consistent with DF-5508 (amdsmb no-quiesce) which this audit rates Info for the weaker lock-only variant.

Fix (validated)

fix.diff (3 files):

• iiconf.c/iiconf.h: new iicbus_bus_owned(bus, dev) accessor.
• iicsmb.c iicsmb_detach(): return EBUSY while the bridge owns the iicbus; propagate bus_generic_detach() errors; NULL-safe child delete.
• smbus.c smbus_detach(): return EBUSY while a client holds the smbus — this closes the smbus/iicsmb driver-module unload path that bypasses iicsmb_detach entirely (iicsmb.c:510 registration).

Fix validation (guest, patched iicbus.ko/iicsmb.ko/smb.ko + rebuilt kernel because smbus is compiled into X86_64_GENERIC):

poc: >>> kldunload iicsmb mid-BREAD (expect EBUSY) <<<
kldunload: can't unload file: Device busy
poc: child still alive? yes (in-flight ioctls completing normally)
poc: >>> kldunload iicsmb after client stopped (expect success) <<<
rc=0
poc: firing INTR_STOP via iicbus_intr after clean unload ...
poc: racefixed done -- GUEST ALIVE, fix validated

Baseline (no fix): panic in freed text. Patched: unload refused during the transaction, clean unload once quiesced, post-unload interrupt is a no-op (owner cleared). Residual: a complete fix would also pin the module across request/release (refcount) rather than refusing detach; the EBUSY guards close every demonstrated window.

Cross-references

• sys/bus/iicbus/iicsmb.c:164-175 (no-quiesce detach), :509-510 (dual driver-module registrations).
• sys/kern/subr_bus.c:853-899 (force-detach on unload).
• sys/bus/iicbus/iiconf.c:45-54,85-148 (owner lifecycle, intr dispatch).
• sys/dev/smbus/smb/smb.c:240-243,356 (transaction holds the bus).

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.