DF-5137 — radeon kv_smc.c: fail-open SMC response validation

File: sys/dev/drm/radeon/kv_smc.c:30-52 (radeon twin of DF-5132, amdgpu)

What: kv_notify_message_to_smu() validates the SMC response by rejecting ONLY the literal values 0xFF and 0xFE. A wait-loop timeout (response 0x0000 = "no response yet") and every undefined response code fall through to return 0 = success. On radeon the hole is WIDER than the amdgpu twin: SMC_RESP_MASK is 0xffff (cikd.h:431), so the response register is compared as a 16-bit value and the literals only match 0x00FF/0x00FE — e.g. a byte-swapped FAILED (0xFF00) or any 0x0102..0xFFFD also reports success.

Impact: the whole kv_dpm.c power-management state machine (37 call sites) proceeds against a wedged SMC believing every message succeeded (DPM enable, BAPM enable, table uploads); kv_dpm_get_enable_mask() (kv_smc.c:54-64) then reads the message-ARG register as a "valid" enable mask after a timed-out query. No attacker-controlled input reaches this path and the SMC SRAM write path fails closed (see VERDICT.md kill trace), so the ceiling is PM desynchronization / GPU hang on already-faulted hardware => Info, matching DF-5132.

Reproduce (static proof; runtime needs Kaveri APU silicon)

sh check_static.sh /home/maxx/dfbsd/dfbsd     # 11 assertions, all must PASS
cat check_static.log

Runtime reproduction is hardware-gated: the audit QEMU guest has zero AMD/ATI PCI devices (pciconf -l | grep -icE 'ati|amd|1002' → 0, see env.txt) and the trigger additionally needs a Kaveri-class APU with a stalled SMC.

Fix

fix.diff (git-apply clean against the unmodified tree) replaces the 0xFF/0xFE whitelist with fail-closed rejection of everything != PPSMC_Result_OK, mirroring the DF-5132 fix for the amdgpu twin. fix_build.log is the full radeon.ko build with the fix applied (compiles clean with -Werror; kv_smc.o linked).

Files

• check_static.sh / check_static.log — mechanical static proof
• fix.diff — the fix, unified diff
• fix_build.log — radeon.ko compile-validation of the fix (guest /usr/src)
• env.txt — guest environment (no AMD hardware)
• manifest.json, verdict.json, VERDICT.md

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.