# DF-5132 — VERDICT

**status: untested (statically certain / runtime not testable on audit guest)**
**reproduced: 0 · impact: none demonstrated (PM state desync on wedged SMC; DoS ceiling)**

## The claim, proven from source

1. **0x00 cannot be a success code.** `sys/dev/drm/amd/amdgpu/ppsmc.h:67-68`:
   `PPSMC_Result_OK = 0x01`, `PPSMC_Result_Failed = 0xFF`; resp `0x00` is the
   "no response yet" state the kv_smc.c:41 loop polls for.
2. **The validator only rejects 0xFF/0xFE** (kv_smc.c:47-52). A timed-out SMC
   leaves `tmp == 0` after the loop; the outer `if (tmp != 1)` body contains no
   catch-all, so control reaches `return 0` at kv_smc.c:54. Same for every
   undefined `0x02..0xFD`.
3. **The CI sibling does not have this hole**: `amdgpu_ci_send_msg_to_smc()`
   (ci_smc.c:170-187) returns `(PPSMC_Result)tmp` raw, so its callers compare
   against `PPSMC_Result_OK` and observe a timeout as failure.
4. **Reachability**: `amdgpu_kv_notify_message_to_smu` is the sole SMC message
   channel for the whole kv_dpm.c state machine (`amdgpu_kv_smc_dpm_enable`,
   `amdgpu_kv_smc_bapm_enable`, `amdgpu_kv_send_msg_to_smc_with_parameter`,
   `amdgpu_kv_dpm_get_enable_mask` — all kv_smc.c:57-120, all invoked from
   kv_dpm.c DPM enable/disable/workqueue paths).

`check_static.sh` (this pack) asserts facts 1–3 mechanically against the tree;
output in `check_static.log`.

## Why severity is Info, not Low+

- No attacker-controlled input reaches this path: the message id is a kernel
  enum and the failure trigger is an SMC firmware/hardware fault.
- No memory-safety consequence: I traced the natural follow-on question —
  "does the fail-open let garbage SRAM values reach an unchecked write?" — and
  it **fails closed**. `amdgpu_kv_copy_bytes_to_smc()`'s outer sum check
  `(smc_start_address + byte_count) > limit` (kv_smc.c:129) can wrap u32 and
  pass, but any address that wrapped is `> limit`, and every inner
  `kv_set_smc_sram_address()` re-checks `(smc_address + 3) > limit`
  (kv_smc.c:83) where wrapping is impossible because the alignment gate at
  kv_smc.c:81 restricts addresses to multiples of 4 (≤ 0xFFFFFFFC). The first
  inner check rejects the copy → `-EINVAL` propagates (kv_dpm.c callers all
  `return ret`). So even a garbage `pi->dpm_table_start` (read from wedged-SMC
  SRAM at kv_dpm.c:589-603) cannot smuggle an out-of-limit SMC SRAM write.
  (This kill is recorded because the radeon ci twin of that outer check *was*
  filed as DF-2105 — on KV the inner re-validation closes it.)
- Realistic ceiling: DPM desynchronization on an already-faulted SMC → wrong
  voltage/clock programming → GPU hang (local DoS). That is a robustness
  defect worth fixing (defense-in-depth, fail-closed), i.e. **Info** per the
  rubric.

## Why no runtime PoC

Guest: DragonFly 6.5-DEVELOPMENT x86_64, **zero AMD/ATI PCI devices**
(`pciconf -l | grep -icE 'ati|amd|1002'` → 0); `amdgpu` cannot attach, and the
defect additionally needs Kaveri-class APU silicon with a stalled SMC. Honest
classification = untested (hardware-gated), with the static proof attached.

## Exploit chain

(none)

## Fix validation

Not applicable (no runtime baseline without Kaveri hardware). `fix.diff`
authored after verification; `git apply --check` passes against the unmodified
tree; it was **not** applied to `sys/`. The same one-line strictness fix should
be mirrored in `sys/dev/drm/radeon/kv_smc.c:44-52` (byte-identical twin).

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