# DF-5205 VERDICT — UNTESTED (hardware-absent; Info-class, Phase V exempt)

**Status: untested. Reproduced: no. Impact: none (code-shape defect is certain;
runtime consequence requires Trinity hardware to demonstrate).**

## What is certain (static proof)

The fail-open is a static property of the code, verified line-by-line:

1. `sys/dev/drm/radeon/trinity_smc.c:36-40` — poll loop breaks on *any* nonzero
   response, or silently falls through after `rdev->usec_timeout` iterations
   (100 ms — `RADEON_MAX_USEC_TIMEOUT`, `sys/dev/drm/radeon/radeon.h:131`,
   set at `radeon_device.c:1300`).
2. `trinity_smc.c:41` — `v = RREG32(SMC_RESP_0)` **unmasked** (register
   `0x230`, `trinityd.h:170`; no `SMC_RESP_MASK` exists for TN — the 0xffff
   masks in `cikd.h:429-431` are CIK/kv-only, and kv's twin applies them at
   `kv_smc.c:35,38,42`).
3. `trinity_smc.c:43-53` — the `if (v != 1)` block returns `-EINVAL` **only**
   for exactly 0xFF and 0xFE; the timeout value 0 and every undefined code
   0x02-0xFD (and any value with stray upper bits) falls through to
   `return 0` at :53.
4. Consumers propagate the false success: `trinity_dpm_enable()`
   (`trinity_dpm.c:1105-1132`) returns 0 unconditionally at :1131 even when
   every SMC message inside it failed open; `trinity_dpm_force_state` /
   `trinity_dpm_n_levels_disabled` results are checked at
   `trinity_dpm.c:836/1221/1226` but will read as success. The radeon DPM core
   then marks the device DPM-enabled against hardware that never acked.

This is the exact family shape already filed as DF-5137 (radeon kv_smc.c) and
DF-5132 (amdgpu kv_smc.c), both Info/certain — trinity is the last SMC file in
the family and the only one additionally unmasked.

## Why not guest-verified

- The single-tenant QEMU guest has no AMD Trinity GPU; `trinity_notify_message_to_smu`
  is only reachable through the radeon DPM code on TN/RL ASICs. There is no
  software-only trigger (no ioctl/sysctl reaches it; message ids are constants —
  `ppsmc.h:173,182` etc.).
- Info severity / no attacker-controlled input → outside the Phase V mandate
  (Critical/High, memcorrupt/privesc/hammer2 buckets, or trivial local PoC).
- Therefore: no PoC authored, no build/run performed, `attempts: 0`,
  `code_hash` hashes the annotated analysis file `analysis.txt`.

## Fix

`fix.diff` adds the missing catch-all (`return -EINVAL` for every `v != 1`
that is not the two defined error codes). Authored against the read-only
`sys/` tree; `git apply --check` verified; **not** hardware-validated
(`fix_status: not_testable`). Never applied to `sys/`.

## Escalation assessment

None. No memory-safety primitive: the bug misreports a hardware-wait outcome
only. Message ids and scratch payloads are kernel constants
(`trinity_smc.c:59-110`); `n` in `trinity_dpm_force_state`/`n_levels_disabled`
comes from driver-computed power-state level counts (`trinity_dpm.c:836,1221,1226`),
never raw user input. Worst case is a GPU left in boot clocks/voltage with a
PM state machine that believes otherwise.

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