# DF-2308 — VERDICT: not reproduced (false positive: the "short successful read" premise is unreachable in-tree)

## Bottom line

The I2CREAD copyout at `sys/bus/iicbus/iic.c:347` does use the requested
length (`s->count`) instead of the actual-read length (`count` set at
:344) — that part of the claim is accurate source reading. But the leak
requires `iicbus_read()` to return **success with a short fill**, and no
in-tree backend can do that:

1. **iicbb** (`sys/bus/iicbus/iicbb.c:409-421`, the only backend on the
   guest and the only one reachable without specific PCF8584 parallel-port
   hardware): the fill loop `while (len) { *buf++ = iicbb_readbyte(...);
   bytes++; len--; }` terminates only at `len == 0`, then `*read = bytes;
   return (0)`. `iicbb_readbyte` (iicbb.c:308-330) has no failure mode —
   it samples the (emulated or real) SDA line 8 times and ACKs/NACKs per
   `last`; a hung bus yields 0xFF *bytes*, not *fewer* bytes. Hence on
   every successful I2CREAD, `count == s->count` and the copyout moves
   exactly the bytes the driver wrote.
2. **pcf** (`sys/bus/iicbus/pcf/pcf.c:586-640`): its only short-read exit
   is `pcf_wait_byte()` failure → `pcf_stop(); goto error;` returning
   `error != 0`, and `iic.c:345-346` breaks to the epilogue **without any
   copyout** on error. (Also unreachable on this guest: PCF parallel-port
   hardware.)

## Live verification (DragonFly 6.5-DEVELOPMENT guest, production KLDs)

Rig: the DF-5539 family harness — real in-tree `iicbus.ko`/`iicbb.ko`/
`iic.ko` on a fake GPIO bit-bang parent `fakebb0` (nexus), emulated slave
ACKs any address byte, read TX pattern 0xc0,0xc1,…. Two disclosed setup
patches (the fixes for sibling findings DF-5559/DF-5560) were required to
make `/dev/iic0` attach and not NULL-deref on first ioctl; **the I2CREAD
logic under test is stock** (verified: only iicbus.c/iic.c attach-path
setup hunks applied; module disasm `stock-vs-setup.disasm.txt` shows the
DF-5560 store in iic_attach and nothing else).

The decisive experiment — same groom that proved chunk recycling for the
sibling I2CRDWR leak (DF-5558, marker returned 12/12 on this same rig):
`groom5558.ko` kmalloc+fill+kfree's an M_TEMP chunk of exactly the I2CREAD
size immediately before each ioctl, so `iic.c:343`'s kmalloc hands I2CREAD
the stale marker chunk itself. Result over 3 runs, sizes
64/256/512/1024/2048 groomed+ungroomed and 16384 ungroomed (51 attempts
per run):

* `rc=0`, `pattern_bad=0` — every byte equals the slave TX pattern
  `(0xc0 + i) & 0xff`
* `marker=no` (searched "ALEHEAP!" anywhere in the buffer — the marker
  tail that survives the allocator's 8-byte chunk header)
* `kptr-qwords=0` (no 0xffff-prefixed kernel pointers)

i.e. **zero bytes of the fresh chunk survive to userspace**; there is no
oracle to harvest, no partial-fill path to exploit.

Error paths (all leaving the 0xAA-prefilled user buffer 100% untouched):
* no-start I2CREAD → EINVAL (iiconf.c:254-259 wrapper gate, `!sc->started`)
* wrong-direction (started byte even) I2CREAD → EINVAL (`!(sc->started &
  LSB)` gate at iiconf.c:259) — this also covers the after-NACK case
  (a NACKed START leaves `started` cleared)

### Probe annotations (rig quirks, not kernel behavior)

* `E2 I2CSTART(0x6e)` returned rc=0 where the probe predicted ENOACK: the
  harness arms `nack_this` at the **falling edge** of the address-ACK
  clock (iicbb_harness.c fakebb_setscl byte-slot-done branch), one
  half-clock after `iicbb_ack`'s rising-edge sample (iicbb.c:271-285
  samples at the 9th clock high). A bare I2CSTART therefore ACKs; the
  NACK surfaces on the following data byte's ACK slot — exactly how
  DF-5539/DF-5558 observed IIC_ENOACK via block writes. Consequence: the
  after-NACK I2CREAD exercised the wrong-direction EINVAL gate instead of
  a post-ENOACK state; equally a no-copyout error path.
* `E3 I2CSTART(0x50)` then returned EIO-class failure because E2 left the
  bus started (iicbus_start wrapper refuses when already started,
  iiconf.c:169-180).

### Incidental observations (notes only, not new findings)

* During rig bring-up, exercising `/dev/iic0` with a **stale unpatched**
  iic.ko re-panicked the kernel exactly as DF-5560 documents
  (`device_get_parent(NULL)` at iic.c:289) — capture kept in
  `panic-setup-df5560-incidental.txt`.
* DragonFly's `patch(1)` assumes `-R` non-interactively on already-applied
  diffs, which silently reverted the setup patches in one intermediate
  round — run.sh now uses source-marker guards.

## Conclusion

`status: not_reproduced`, `reproduced: 0`, `impact: none`,
`confidence: certain`. The finding is a true statement about a latent API
misuse but an incorrect statement about exploitable behavior on this tree.
Recommended hardening (not a security fix): make the copyout honor the
backend's actual count — `error = copyout(buf, s->buf, count);` — so a
future backend honoring the short-read contract cannot reintroduce the
disclosure. No fix.diff authored (pure false positive per contract).

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

(No fix.diff for this item: documented recommendation only - see Fix above.)