DF-5634 — children are created with no struct iicbus_ivar ever allocated (the DF-5559 root): iicbus_write_ivar returns success while discarding every address write

• File under audit: sys/bus/iicbus/iicbus.c (pass 2) — root-cause file of DF-5559, whose validated fix patched only the accessor half
• Class: incomplete plumbing / silent data loss (hardening completion)
• Severity: Info (no memory-safety consequence by itself; the uninitialized-read consequence was DF-5559)
• Verdict: REPRODUCED (stock: ENXIO + untouched value; with DF-5559's fix: write returns 0 but the value is silently dropped), fix validated

The defect

struct iicbus_ivar (iicbus.h:44-47) exists and the generated accessor iicbus_get_addr() (iicbus.h:53-56, __BUS_ACCESSOR) routes through BUS_READ_IVAR/BUS_WRITE_IVAR, but nothing in iicbus.c ever:

• allocates an ivar for a child — iicbus_attach (:144-146) and iicbus_add_child (:164-171) create children bare (make_device leaves dev->ivars = NULL, subr_bus.c);
• implements bus_read_ivar/bus_write_ivar (absent from iicbus_methods, :59-73) — the uninitialized-stack half, filed and fixed as DF-5559;
• frees ivars (bus_child_detached absent).

This is the "longer term allocate iicbus_ivar for children in bus_add_child per FreeBSD" item from the 2026-10-07 task_log lead. Even with DF-5559's validated fix (read/write_ivar added, NULL-tolerant), every child still has ivar == NULL, so:

case IICBUS_IVAR_ADDR:
        if (ivar != NULL)                 /* never true */
                ivar->addr = (uint32_t)value;
        return (0);                       /* success -- value discarded */

— iicbus_write_ivar reports success while dropping the write, so no code path can ever set an iicbus child address through the official interface (there is no in-tree writer today; the hazard is for the same future consumers DF-5559 flagged, and the accessor contract itself).

Reproduction (guest)

• Stock (run_a2.log): BUS_WRITE_IVAR(iicbus0, child, IICBUS_IVAR_ADDR, 0x42) → error 6 (ENXIO); BUS_READ_IVAR → error 6 with the result variable untouched at 0x42424242 — nobody behind the method (DF-5559's uninit class, re-proven from the provider side).
• iicbus.ko + DF-5559 fix (run_b_5559.log): WRITE_IVAR(0x42) error=0 (success!) but READ_IVAR val=0x0 — the write was silently discarded; iicbus_get_addr() == 0 forever.
• Fixed (run_d_fixed.log): with fix.diff allocating ivars in the corrected bus_add_child (and freeing them in the new bus_child_detached): WRITE error=0, READ val=0x42, iicbus_get_addr=0x42 — the round trip works.

Fix

fix.diff (shared with DF-5632): iicbus_add_child allocates a zeroed struct iicbus_ivar and device_set_ivars(child, ivar); iicbus_child_detached frees it; the DF-5559 accessors now have a live ivar to serve. Also removes the dead DEVTOIICBUS macro (iicbus.c:44) that still casts to the nonexistent struct iicbus_device.

DF-5634 VERDICT — REPRODUCED (silent ivar write drop; the DF-5559 root), fix validated

See README.md for the full narrative. Summary of the decisive evidence:

• Stock (../DF-5632/run_a2.log): IVAR_RT: WRITE_IVAR(0x42) error=6, READ_IVAR error=6 val=0x42424242 — ENXIO, result untouched (the DF-5559 uninitialized class, seen from the provider side).
• iicbus.ko + DF-5559's own validated fix (run_b_5559.log): WRITE_IVAR(0x42) error=0 then READ_IVAR error=0 val=0x0 iicbus_get_addr=0x0 — the write reports success and is silently discarded, because no child ever has an ivar allocated (iicbus.c:144-146, :164-171 create children bare; make_device leaves dev->ivars = NULL).
• Fixed (../DF-5632/run_d_fixed.log): dfctl ivar: v1=0x42 v2=0x42 — write/read/accessor round trip works with fix.diff's allocation in the corrected bus_add_child + bus_child_detached free.

Impact: none by itself (hardening completion of the accessor contract); the memory-safety consequence of the missing read side was DF-5559.

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.