# VERDICT — DF-4549

**Status: not_reproduced** (kernel path hardware-gated; the logic defect itself
is proven by a compiled demo run on the guest). **Impact: none on this guest**
(data-integrity bug on real VIA hardware; root-only reachability via
`/dev/smbN`, which is `make_dev(..., UID_ROOT, GID_WHEEL, 0600, "smb%d")` —
sys/dev/smbus/smb/smb.c:139-141).

## Root cause (path:line)

`viapm_wait()` — sys/dev/powermng/viapm/viapm.c:567-605:

```c
int count = 10000;
u_char sts = 0;
...
while(count--) {                       // :574
        DELAY(10);
        sts = VIAPM_INB(SMBHST);
        if (!(sts & SMBHST_BUSY) && (sts & SMBHST_INTR))
                break;                 // success path
}
...
if (!count)                            // :587
        error |= SMB_ETIMEOUT;
```

`count` is `int`. `while (count--)` post-decrements: the tested value is the
PRE-decrement value; when the tested value is 0 the loop exits and `count`
holds **-1**. Therefore:

1. **Genuine timeout** (controller stuck with `SMBHST_BUSY`, or never raising
   `SMBHST_INTR`): after all 10000 polls (100 ms), `count == -1`, `!count` is
   false, `SMB_ETIMEOUT` is **never set**. `viapm_wait()` returns `SMB_ENOERR`
   (unless stale status bits happen to hold FAILED/COLLID/ERROR), so
   `viasmb_recvb` (viapm.c:690-691), `viasmb_readb` (736-737),
   `viasmb_readw` (784-789) and `viasmb_bread` (849-862) all return "success"
   and hand the caller **stale SMBHDATA0/1 register contents as fresh data**
   (`viasmb_bread` even reports the stale `len` byte as the transfer count —
   interacting with DF-1691). Write ops (`viasmb_quick/sendb/writeb/writew/
   bwrite`) "succeed" without any transfer having completed. Callers that
   consume SMBus data for decisions (thermal/battery/EEPROM readers, root via
   `/dev/smbN` ioctl SMB_READB/READW/BREAD/TRANS — smb.c:272-330) get
   silently-wrong data with no error.

2. **Success on the final poll** (INTR lands exactly on the 10000th
   iteration): `break` leaves `count == 0`, `!count` is true, and a
   **successful** transaction is spuriously failed with `SMB_ETIMEOUT`.

## Proof

Compiled demo (`viapm_wait_offbyone_demo.c`, built with guest `cc 8.3
[DragonFly]`) reproducing the exact loop shape:

```
case A (perpetual BUSY, real timeout): error=0x0 -> *** SMB_ETIMEOUT MISSING ... ***
case B (INTR on final poll, success):   error=0x20 -> *** SPURIOUS SMB_ETIMEOUT ... ***
```

(finding run.log — full untrimmed output.)

## Why not reproduced in-kernel here

`viapm.ko` loads on the guest but never attaches: `pciconf -l` shows no VIA
1106:30xx/31xx PMU device (guest_hw_evidence.txt). The bug is exercised by
every real SMBus transaction on affected VIA hardware; no QEMU device model
exists for it. Both failure modes are deterministic C semantics, hence
confidence `certain` for the defect itself.

## Exploit chain

None — silent wrong-data / missing-error logic bug (not memory corruption).
Reachable by root only through the 0600 `/dev/smbN` node on VIA-hardware
hosts, and by in-kernel smbus consumers.

## Fix validation

Not performed (no memory corruption reproduced; kernel path hw-gated). The
`done`-flag diff in `fix.diff` is line-accurate against viapm.c:567-605 and
semantically verified by the demo (case A -> timeout reported, case B ->
success reported when the flag variant is applied by inspection).

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