# DF-1095 — iicsmb_bwrite leaves I2C bus in STARTED state on write failure

## Build

```
cc -O0 -o df1095_harness df1095_harness.c
cc -O0 -DFIX -o df1095_harness_fix df1095_harness.c
```

## Run

```
./df1095_harness        # bus stuck STARTED, phase 2 returns EINVAL
./df1095_harness_fix    # bus released, phase 2 works
sh verify.sh            # 8 static source checks
```

## Expected (bug present)

- `verify.sh` reports `PASS=8 FAIL=0`: the `iicsmb_bwrite` `error:` label
  lacks `iicbus_stop`, while the sibling `iicsmb_bread` has it (control
  case); `iicbus_start` sets `sc->started`; `iicbus_start` rejects with
  `EINVAL` when `started` is already set; `iicbus_stop` clears it.
- `df1095_harness` phase 1 leaves `started != 0`; phase 2 returns
  `EINVAL` and prints `BUG: bus still STARTED ... permanently wedged`.
- `df1095_harness_fix` releases the bus in phase 1; phase 2 succeeds.

## Bug shape

`iicsmb_bwrite` at `sys/bus/iicbus/iicsmb.c:462-482` is the **only**
SMBus method in the file that does not call `iicbus_stop()` in its error
cleanup. After `iicbus_start()` succeeds (setting `sc->started = slave`,
`iiconf.c:178`), any failure in `iicbus_write()` jumps to the `error:`
label at `:480-481`, which is a bare `return (error)` — no STOP is
issued. `sc->started` stays set; every subsequent `iicbus_start()` on
that bus returns `EINVAL` (`iiconf.c:174-175`). The entire SMBus bridge
is therefore permanently wedged for **all consumers** (`/dev/smb`,
kernel sensors, battery/thermal monitors, IPMI SSIF) until driver reload
or reboot.

The sibling `iicsmb_bread` (`:484-507`) **does** call `iicbus_stop()`
in its `error:` label (`:505`), as do all other read/write methods in
the file. `iicsmb_bwrite` is the sole outlier.

## Impact / preconditions

Two reachable paths:

1. **Local root** via `SMB_BWRITE` ioctl to a slave that ACKs the
   address byte but NACKs the first data byte (perfectly legal SMBus
   behavior for many slave controllers).
2. **Untrusted peripheral** — a malicious/untrusted I2C device
   (USB-C/Thunderbolt dock with embedded I2C controller, BMC, etc.)
   NACKs mid-transaction.

Either path permanently disables the SMBus bridge — DoS for all
I2C/SMBus consumers on that bus.

The audit QEMU guest has no `iicbus`/`iicsmb` devices in dmesg, so the
path is not exercised dynamically here; the bug is confirmed by source
trace + harness.