DF-5539 — iicbb_print_child() discloses an uninitialized kernel stack byte

sys/bus/iicbus/iicbb.c:164-186

What

iicbb_print_child() declares u_char oldaddr; (iicbb.c:169) uninitialized, hands &oldaddr to the parent driver's iicbb_reset method (iicbb.c:173), and — whenever that call does not return IIC_ENOADDR — prints the byte to the console and writes it back as the "restored" bus address (iicbb.c:179-182):

iicbus0: <Philips I2C bus> on iicbb0 addr 0xff

No in-tree iicbb parent ever fulfills the "return 0 and fill *oldaddr" contract: lpbb_reset returns IIC_ENOADDR on success and returns 0 without writing *oldaddr on its ppbus-busy path (sys/dev/misc/lpbb/lpbb.c:186-190); viabb_reset and cxm_iic_reset always return IIC_ENOADDR. So the only way the else-branch (iicbb.c:177-183) can execute in-tree is with oldaddr never written — every execution of those lines reads uninitialized kernel stack.

How to reproduce (production-code KLD harness — no bit-bang hardware)

The guest has no GPIO/ppbus bit-bang hardware, so the harness instantiates the real, unmodified in-tree iicbb.ko under a fake GPIO parent:

• iicbb_reg.ko — registers the real iicbb_driver/iicbb_devclass on a fake bus fakebb, exactly like the in-tree DRIVER_MODULE(iicbb, lpbb/viapm/...) declarations (iicbb.c:441-445).
• iicbb_harness.ko — a fakebb device on nexus0 whose iicbb_if methods emulate the GPIO pins plus a wired I2C slave (START/STOP detection, SCL-edge sampling, ACK/NACK injection, TX pattern generator). fakebb_reset() faithfully reproduces lpbb's ppbus-busy contract violation: returns 0, never writes *oldaddr.

On load, newbus walks identify → probe → attach (sys/kern/subr_bus.c:3007-3013, print at subr_bus.c:2004), the cascade fakebb0 → iicbb0 → iicbus0 runs inside fakebb_attach, and iicbb_print_child prints the uninitialized byte. The harness then drives the real transfer state machine through the public iicbus API (write-echo, read-pattern, NACK → IIC_ENOACK + bus-stopped, repeated-start read) to demonstrate the driver is exercised end-to-end.

Build (on the DragonFly guest, as root, in /root/df5539)

./build.sh          # builds iicbb_reg.ko + 4 harness variants
                    # (a5/5a/37: stack pre-sprayed; none: no spray)

Run

kldload /boot/kernel/iicbus.ko
kldload /boot/kernel/iicbb.ko
kldload /usr/obj/root/df5539/build_reg/iicbb_reg.ko
kldload /usr/obj/root/df5539/build_a5/iicbb_harness.ko   # etc. per variant
dmesg | grep 'on iicbb0 addr'
./run.sh            # does all of the above + 8 load/unload cycles

Expected

• Stock kernel/modules: iicbus0: <Philips I2C bus> on iicbb0 addr 0xff on every attach (16/16 observed; value is stack junk — allocator fill on this system, see VERDICT.md for the spray experiment and the disassembly proof that the slot is never written).
• State machine green: write ok=1 read_ok=1, nacked-write: error=2 (IIC_ENOACK=2) bus_started_after=0, repstart-read: byte=0xc0.
• With fix.diff applied to iicbb.c and only iicbb.ko rebuilt: addr 0x0 (deterministic, no uninitialized data), state machine unchanged.

Fix

See fix.diff (also inline in the finding): initialize oldaddr = 0 and take the else-branch only on error == IIC_NOERR.

DF-5539 — VERDICT

Status: reproduced (leak, Low) — one byte of uninitialized kernel stack disclosed to the console / dmesg by iicbb_print_child() every time an iicbus child attaches under iicbb with a parent whose reset returns 0 without filling *oldaddr. Fix validated (patched iicbb.ko → deterministic addr 0x0).

Root cause

sys/bus/iicbus/iicbb.c:164-186:

u_char oldaddr;                                                    /* :169, uninitialized */
error = IICBB_RESET(device_get_parent(bus), IIC_FASTEST, 0, &oldaddr); /* :173 */
if (error == IIC_ENOADDR) { ... master-only ... }
else {
        IICBB_RESET(device_get_parent(bus), IIC_FASTEST, oldaddr, NULL); /* :179 restore w/ garbage */
        retval += kprintf(" on %s addr 0x%x\n",
                         device_get_nameunit(bus), oldaddr & 0xff);       /* :181-182 LEAK */
}

The iicbb_if reset contract has two outcomes: IIC_ENOADDR ("no address") or "success" with *oldaddr filled. Audit of all in-tree parents:

• lpbb_reset (sys/dev/misc/lpbb/lpbb.c:182-201): on the ppbus-busy error path (ppb_request_bus(..., PPB_DONTWAIT) fails, lpbb.c:186-190) it prints "can't allocate ppbus" and returns 0 (IIC_NOERR) without writing *oldaddr — iicbb.c:173-185 then reads, prints, and "restores" the uninitialized byte. On success it returns IIC_ENOADDR (never fills either).
• viabb_reset (sys/dev/powermng/viapm/viapm.c:507-514): always IIC_ENOADDR, never fills.
• cxm_iic_reset (sys/dev/video/cxm/cxm_i2c.c:273-296): always IIC_ENOADDR, never fills.

Therefore the else-branch at iicbb.c:177-183 cannot execute with a written oldaddr on this tree: it is reachable only through lpbb's busy path (or any out-of-tree parent with the same shape), and every such execution reads uninitialized kernel stack. This is the iicbb member of the family class filed this pass for iicsmb.c (DF-5523, uninitialized bcount).

Reachability

• Boot with any iicbb parent present (lpbb on ppbus, viapm 586B, cxm_iic), or kldload the stack (root) — the leak fires during the attach cascade, once per iicbus attach (sys/kern/subr_bus.c:2004 → device_print_child).
• The printed line lands on the console and in the message buffer; dmesg is readable by unprivileged users (no dmesg_restrict on DragonFly), as is /var/log/messages via syslogd (default *.notice kernel facility).
• Trigger privilege: attaching hardware / loading the module requires root or boot-time presence; the disclosure is then readable by any local user.

Verification (QEMU guest, DragonFly 6.5-DEVELOPMENT x86_64)

No bit-bang hardware exists in the rig, so a production-code KLD harness instantiates the stock in-tree iicbb.ko under a fake GPIO parent (iicbb_reg.ko + iicbb_harness.c — the fake parent implements the full iicbb_if vtable with an emulated I2C slave; fakebb_reset reproduces lpbb's busy-path contract byte-for-byte: return 0, never write *oldaddr).

1. Leak reproduced: 8 load/unload cycles per run across 3 spray variants + no-spray, 16/16 attach events printed iicbus0: <Philips I2C bus> on iicbb0 addr 0xff (run.out, dmesg.out). The byte is the untouched stack slot content — allocator fill (0xff) on this system.
2. Spray experiment: the harness pre-sprays ~5 KB of kstack below the cascade with 0xa5/0x5a/0x37 before newbus triggers attach (fakebb_identify). The leaked byte stayed 0xff: the slot is rewritten after the spray by the device_add_child/kmalloc internals that run between identify and print_child at exactly that stack depth. This does not weaken the finding — it shows the disclosed byte is whatever the kernel's own earlier execution left there (on other systems/paths: pointer fragments), i.e. genuinely uninitialized data.
3. Machine-code proof (stock_disasm.txt, /boot/kernel/iicbb.ko): oldaddr lives at -0x21(%rbp); the function contains exactly one lea -0x21(%rbp),%rcx (passing &oldaddr to the parent reset) and two movzbl -0x21(%rbp) reads (restore call + kprintf) — no instruction writes the slot. With fakebb_reset also proven not to write it (source + resets_with_oldaddr=1 counter), the printed byte is uninitialized stack by construction.
4. State machine driven end-to-end through the real driver (checklist a-d): * block write: 8 bytes de ad be ef 55 aa 12 34 bit-banged out, slave shift-register captured them exactly (slave_rx=deadbeef55aa1234, write_ok=1) — byte counter / ACK handling correct; * block read: slave pattern c0..c7 returned intact (read_ok=1) — last-byte NACK signaling (iicbb_read's (len==1)?last:0) correct; * NACKed address: iicbb_start → IIC_ENOACK (=2) with the bus stopped afterwards (bus_started_after=0) — error path at iicbb.c:359-368 correct; * repeated start mapped to iicbb_start (iicbb.c:92): write byte + repeated start + read byte round-trip succeeded (byte=0xc0); * resets=3 resets_with_oldaddr=1 matches the exact call pattern iicbus.c:125 (NULL), iicbb.c:173 (&oldaddr — the leak call), iicbb.c:179 (restore, NULL).
5. Fix validated: fix.diff applied to the guest's /usr/src copy of iicbb.c, only iicbb.ko rebuilt (module — no kernel rebuild), harness re-run: output changed from addr 0xff to the deterministic addr 0x0, zero occurrences of the uninitialized byte (fix_dmesg.out), state machine still green. Patched disassembly (fix_disasm.txt) shows the new movb $0x0,-0x21(%rbp) prologue store. Stock module restored afterwards.

Impact ceiling

One byte of uninitialized kernel stack per attach event, readable by any local user via dmesg/syslog; plus a garbage byte written as the "restored" i2c address (harmless for in-tree parents — they ignore the addr argument). Not exploitable beyond information disclosure; severity Low (root/boot-triggered, 1 byte, console medium). No escalation path exists for this class.

Honest notes / dead ends

• The stack-spray could not claim the specific slot (overwritten by in-cascade kmalloc internals) — documented above; the disassembly + 16/16 deterministic 0xff disclosure carries the proof instead.
• First harness iteration double-faulted on the kstack guard (spray recursion too deep) — harness bug, fixed at 24 frames; not a target property.
• Adjacent-file observations made while verifying (out of scope for DF-5539, recommend separate review): iicbus.c:144-146 adds ic/iic/iicsmb children with plain device_add_child (no struct iicbus_ivar ivars) while iic.c:115 iicbus_get_addr() dereferences device_get_ivars() — a NULL deref hazard when a child driver probes those children; iic.c:366-369 (I2CRDWR) copies out IIC_M_RD buffers even when the transfer failed, disclosing fresh uninitialized kmalloc memory.

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.