# DF-5137 — VERDICT

**status: untested (statically certain / runtime hardware-gated)**
**reproduced: 0 · impact: none demonstrated (PM state desync on a wedged SMC; local DoS ceiling)**

## The claim, proven from source (check_static.log — 11/11 PASS)

1. **0x00 cannot be a success code.** `sys/dev/drm/radeon/ppsmc.h:67-68`:
   `PPSMC_Result_OK = 0x01`, `PPSMC_Result_Failed = 0xFF`. Response `0x0000`
   is the "no response yet" state that the wait loop at `kv_smc.c:37-41`
   polls for (`!= 0` breaks the loop).
2. **The validator only rejects 0xFF/0xFE** (`kv_smc.c:44-49`). A timed-out
   SMC leaves `tmp == 0` after the loop; the `if (tmp != 1)` body contains no
   catch-all, so control reaches `return 0` at `kv_smc.c:51`. Same for every
   undefined code.
3. **Radeon-specific widening:** `SMC_RESP_MASK` is `0xffff`
   (`sys/dev/drm/radeon/cikd.h:431`), so `tmp` is 16 bits wide and the
   literal comparisons match only `0x00FF`/`0x00FE`. A response of `0xFF00`
   (byte-swapped `FAILED`), `0x0102`, … all return success. The amdgpu twin
   (DF-5132) compares the same mask but the radeon file documents the hole
   against its own driver siblings:
4. **The radeon siblings do NOT have this hole:** `si_send_msg_to_smc()`
   (`si_smc.c:172-190`) and `rv770_send_msg_to_smc()` (`rv770_smc.c:424-448`)
   return the raw `(PPSMC_Result)tmp`, so their callers compare against
   `PPSMC_Result_OK` and observe a timeout as failure. KV is the only radeon
   SMC wrapper that swallows it.
5. **Reachability:** `kv_notify_message_to_smu` is the sole SMC message
   channel for the kv_dpm state machine (`kv_smc_dpm_enable`,
   `kv_smc_bapm_enable`, `kv_send_msg_to_smc_with_parameter`,
   `kv_dpm_get_enable_mask` — 37 references in kv_dpm.c). On `ret == 0` the
   enable-mask query reads the ARG register (`kv_smc.c:60-61`), propagating
   wedged-SMC garbage into PM decisions.

## Why severity is Info (rubric), identical reasoning to DF-5132

- No attacker-controlled input reaches the path: the message id is a kernel
  enum (`id & SMC_MSG_MASK` at kv_smc.c:35); the trigger is SMC
  firmware/hardware fault.
- No memory-safety consequence — I re-traced the natural follow-on for the
  RADEON file: `kv_copy_bytes_to_smc()`'s outer check
  `(smc_start_address + byte_count) > limit` (`kv_smc.c:125`) can wrap u32
  and pass, but every inner `kv_set_smc_sram_address()` re-validates
  alignment (`smc_address & 3`, kv_smc.c:78) and
  `(smc_address + 3) > limit` (kv_smc.c:80-81) where wrap is impossible for
  4-aligned addresses (≤ 0xFFFFFFFC + 3). The first inner check rejects the
  copy → `-EINVAL` propagates; all kv_dpm.c callers `return ret`. So even a
  garbage `pi->dpm_table_start` (read from wedged-SMC SRAM via
  `kv_process_firmware_header`, kv_dpm.c:451-471, bounded reads at fixed
  header offsets `SMU7_FIRMWARE_HEADER_LOCATION + offsetof(...)`,
  smu7.h `0x20000`, limit `pi->sram_end` set at kv_dpm.c:2738) cannot smuggle
  an out-of-limit SMC SRAM write. **Fails closed.**
- Wait-loop bound: `rdev->usec_timeout = RADEON_MAX_USEC_TIMEOUT = 100000`
  (100 ms) set at `radeon_device.c:1300` — bounded, no unbounded spin.
- Realistic ceiling: DPM desynchronization on an already-faulted SMC → wrong
  voltage/clock programming → GPU hang (local DoS). Defense-in-depth /
  fail-closed robustness fix => **Info**.

## Why no runtime PoC

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

## Relationship to knowns / twins

- Independent of DF-2135 (missing smc_idx_lock — the register-access
  serialization issue); this finding is the response VALIDATOR.
- Byte-identical logic twin of DF-5132 (amdgpu kv_smc.c:33-55), explicitly
  anticipated in DF-5132's notes ("radeon/kv_smc.c:30-52 … carries the same
  fall-through"). This is the radeon-side filing.

## Fix validation

Runtime not possible (no hardware); compile validation performed: fix.diff
applied to the guest /usr/src and `radeon.ko` rebuilt — full `-Werror` build
succeeded, kv_smc.o linked (fix_build.log). `git apply --check` clean against
the unmodified repo tree.

## Exploit chain

(none)

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