DF-5635 — iicbus_detach swallows bus_generic_detach() failure → driverless NULL-softc bus with an attached child → NULL-page fault in iicbus_request_bus

• File under audit: sys/bus/iicbus/iicbus.c (pass 2)
• Class: lifecycle error-handling → kernel NULL-page out-of-bounds read → panic (local DoS)
• Severity: Low (requires a child whose detach fails — root-gated setup; in-tree iicsmb's DF-5521-guarded detach is the natural producer)
• Verdict: REPRODUCED (Fatal trap 12, fault VA 0x8, at iicbus_request_bus+0x89: movq 0x8(%r12),%rax = sc->owner, iiconf.c:101), fix validated

The defect

static int
iicbus_detach(device_t dev)                     /* iicbus.c:156-162 */
{
    iicbus_reset(dev, IIC_FASTEST, 0, NULL);
    bus_generic_detach(dev);                 /* return value DISCARDED */
    return (0);                              /* always success */
}

bus_generic_detach (subr_bus.c) detaches children and returns the first child's error (e.g. EBUSY from a busy client). iicbus_detach ignores it and returns 0, so device_detach(iicbus0) believes the driver detached cleanly and completes the teardown:

• device_set_driver(iicbus0, NULL) — softc kfree'd (subr_bus.c, device_set_driver) and kobj switched to null_class;
• dev->state = DS_NOTPRESENT.

…while the failing child is still DS_ATTACHED under the now-driverless bus. The child's very next bus operation, iicbus_request_bus(bus, dev, how) (iiconf.c:86-117), does

struct iicbus_softc *sc = device_get_softc(bus);   /* iiconf.c:88: NULL */
...
if (sc->owner && sc->owner != dev)                 /* iiconf.c:101: *0x8 */

→ read at address offsetof(struct iicbus_softc, owner) == 8 on a NULL base → Fatal trap 12.

The DF-5563 question ("does the iiconf drain/dying protocol need anything from this file's detach?") is answered yes: DF-5563's validated fix already patches iicbus_detach with the dying-flag + wakeup(sc) + drain loop this file owes the waiter protocol — that half is DF-5563's and is not re-reported here. This finding covers the independent defect living at the same lines: the swallowed child-detach error.

Reproduction (guest, stock modules)

run_c_panic.sh / panic_5635_stock.txt — the rig attaches a client child (df5632k0) whose detach returns EBUSY on demand, then drives the production APIs:

[df5632] df5632k0 detach: REFUSING (EBUSY)
iicbus0: detached
[df5632] DETACH_BUS: device_detach(iicbus0) returned 0  (child df5632k0 busy=1)
[df5632] DETACH_BUS-post: ... driver=(NONE-DRIVERLESS) state=0 softc=0
[df5632] DETACH_BUS-post: child[3] devclass=df5632k unit=0 driver=df5632k state=3
[df5632] REQBUS: calling iicbus_request_bus(iicbus0, self, WAIT|INTR)
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
Stopped at      iicbus_request_bus+0x89:  movq 0x8(%r12),%rax

The swallow (returned 0 while the child refused), the inconsistent state (driverless bus with softc=0 + attached child), and the predicted NULL-deref (fault VA exactly offsetof(owner)=8) are all on the serial console.

Fix (validated)

fix.diff propagates the error: error = bus_generic_detach(dev); return (error); (and propagates iicbus_reset's error too; composes trivially with DF-5563's drain block). Fixed module (run_d_fixed.log): device_detach returned 16 (EBUSY), the bus stays driver=iicbus state=3 softc=0xfffff8008d581130 (attached, alive), the child stays attached, and iicbus_request_bus on the still-attached bus returns 0 (request+release clean). No panic anywhere.

DF-5635 VERDICT — REPRODUCED (swallowed child-detach error → NULL-softc deref panic), fix validated

See README.md for the full narrative. Decisive evidence (stock, panic_5635_stock.txt):

[df5632] df5632k0 detach: REFUSING (EBUSY)
iicbus0: detached
[df5632] DETACH_BUS: device_detach(iicbus0) returned 0  (child df5632k0 busy=1)   <- THE SWALLOW
[df5632] DETACH_BUS-post: iicbus=... driver=(NONE-DRIVERLESS) state=0 softc=0     <- softc freed
[df5632] DETACH_BUS-post: child[3] devclass=df5632k unit=0 driver=df5632k state=3 <- child still attached
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8                                    <- offsetof(iicbus_softc, owner)
Stopped at      iicbus_request_bus+0x89:  movq 0x8(%r12),%rax   <- iiconf.c:101 sc->owner

Fixed (run_d_fixed.log): device_detach(iicbus0) returned 16 (EBUSY), bus stays driver=iicbus state=3 softc=0xfffff8008d581130, REQBUS: returned 0 on the attached bus, clean unload — the inconsistent state and the panic are gone.

DF-5563 lead answer: the iiconf drain/dying protocol DOES require this file's detach to wake/drain waiters — DF-5563's validated fix.diff already adds that block to iicbus_detach; this finding is the independent swallowed-error defect at the same lines.

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.