# 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:

```c
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).