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