DF-5633 — iicbus_attach unconditionally re-creates the ic/iic/iicsmb trio on every attach → unbounded child leak + duplicate /dev/iicN nodes on one bus

• File under audit: sys/bus/iicbus/iicbus.c (pass 2)
• Class: resource leak / device-topology corruption (logic, DoS)
• Severity: Low (root-gated: any detach+re-attach of an iicbus with a resident bridge)
• Verdict: REPRODUCED (3→9 children in 2 cycles; /dev/iic0..3 on one bus), fix validated

The defect

iicbus_attach (iicbus.c:144-146) creates the well-known rendezvous children unconditionally:

device_add_child(dev, "ic", -1);
device_add_child(dev, "iic", -1);
device_add_child(dev, "iicsmb", -1);

with no device_find_child guard and no deletion counterpart. Children survive teardown of the bus driver: devclass_delete_driver (subr_bus.c:853-899, the kldunload path) detaches iicbus0 but never deletes its FIXEDCLASS children, and iicbus_detach (iicbus.c:156-162) doesn't delete them either. Every later re-attach of the same iicbus device (device_probe_and_attach after a kldload iicbus.ko with a resident bridge, a rescan, or any driver re-registration) runs iicbus_attach again and mints a second complete trio:

• +3 leaked struct bsd_device (M_BUS kmalloc, each ~0x2c0 bytes) per cycle, unbounded;
• duplicate devclass units (iic0, iic1, ... — each new child is probe/attachable by iic.ko, producing multiple /dev/iicN character devices on ONE physical bus, each with its own sc_addr state → divergent transactions and permanent confusion about bus ownership;
• the duplicates also break iicbus_transfer_gen's single-child expectation (iiconf.c:365, nkid != 1 → EIO) even further.

In-tree masking: MODULE_DEPEND(iicbb, iicbus) prevents kldunload iicbus.ko while a module bridge is loaded, so the leak needs a bridge that stays resident across the iicbus driver's removal — a bridge compiled into the kernel (device iicbb + module iicbus), an out-of-tree bridge without the dependency, or any code that detaches and re-probes the iicbus device (exactly what kldunload/kldload do internally via devclass_delete_driver/devclass_add_driver).

Reproduction (guest, stock modules)

run_a_stock.sh / run_a2_dmesg.txt: /dev/df5632 ioctl driving the production APIs device_detach(iicbus0) + device_probe_and_attach(iicbus0) (the same functions the module handlers call):

[df5632] STAT: nchildren=3                      (ic, iic, iicsmb; iicbus0 attached)
[df5632] CYCLE 0: detach+reattach ok
[df5632] CYCLE 1: detach+reattach ok
[df5632] CYCLE-done: nchildren=9
[df5632] CYCLE-done: child[3] devclass=ic unit=1 ... child[4] iic unit=1 ...
                      child[6] ic unit=2 ... child[8] iicsmb unit=2

run_b_5559.log (iicbus.ko + DF-5559's validated read/write_ivar fix so iic.ko can attach): duplicate char devices on one bus after cycles:

/dev/iic0  (before)
/dev/iic0 /dev/iic1        (after 1 cycle)
/dev/iic0 /dev/iic1 /dev/iic2 /dev/iic3   (after 3 cycles)

Fix (validated)

fix.diff guards the trio with device_find_child(dev, "<name>", -1) == NULL (mirroring the guards iic_identify/iicsmb_identify already have) and routes creation through the corrected BUS_ADD_CHILD. With only iicbus.ko rebuilt (run_d_fixed.log): nchildren stays constant across cycles — after 2 cycles with two extra rig children the count is 5 and does not grow (CYCLE-done: nchildren=5, identical before/after).

DF-5633 VERDICT — REPRODUCED (unbounded child-trio leak + duplicate /dev/iicN), fix validated

Root cause (path:line)

iicbus_attach (sys/bus/iicbus/iicbus.c:144-146) re-creates the ic/iic/iicsmb rendezvous trio on EVERY attach, unguarded. Children are never deleted by iicbus_detach (iicbus.c:156-162) nor by devclass_delete_driver (sys/kern/subr_bus.c:853-899, the kldunload force-detach path — it only detaches devices of the iicbus devclass), so each detach+re-attach cycle of the same iicbus device accumulates another trio of struct bsd_device (M_BUS) and mints duplicate devclass units.

Evidence

• Stock, run_a2_dmesg.txt: STAT: nchildren=3 → 2 production detach/re-attach cycles (device_detach + device_probe_and_attach, exactly what kldunload/kldload invoke) → CYCLE-done: nchildren=9 with ic/iic/iicsmb units 0,1,2 — 6 leaked device structs in 2 cycles, unbounded by repetition. Also visible: iicbus0's softc address changes between STATs (freed on detach, reallocated on re-attach) while the children persist — the asymmetry that makes the leak.
• With iic.ko attachable (iicbus.ko + DF-5559 fix), run_b_5559.log: /dev/iic0 → /dev/iic0,1 → /dev/iic0,1,2,3 — duplicate char devices bound to ONE physical iicbus0, each with independent sc_addr state; also further breaks iicbus_transfer_gen's nkid != 1 check (iiconf.c:365).

Reachability honesty

The cycle requires a detach+re-attach of an iicbus whose bridge stays resident. In-tree stock configs are partly fenced by MODULE_DEPEND(iicbb, iicbus) (kldunload iicbus refused while iicbb.ko loaded), so the practical triggers are: a kernel-compiled bridge (device iicbb in the kernel config) with modular iicbus, an out-of-tree bridge without the dependency, or any rescan/driver-rebind flow. The rig drives the identical production functions, so the code path is proven; the privilege gate is root (kldload/rescan). Severity Low per family rubric.

Fix validation

fix.diff guards each trio member with device_find_child(dev, name, -1) == NULL. Fixed module (run_d_fixed.log, run_d_fixed_dmesg.txt): after creating two extra children (df5632c via BUS_ADD_CHILD, df5632k0 via device_add_child) and running 2 cycles, nchildren=5 before AND after — no growth; unload clean; guest healthy.

Distinction from the family findings

DF-5521/DF-5563 are iicsmb/iiconf teardown protocol bugs; DF-5559 is the ivar consumer. This finding is the attach-side topology bug in iicbus.c itself (its only prior mention was a 2026-10-06 task_log lead from the pcf pass, now root-caused and proven).

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.