DF-5132 — amdgpu_kv_notify_message_to_smu() fail-open response validation: SMC timeout (0x00) and undefined codes (0x02–0xFD) reported as success

File: sys/dev/drm/amd/amdgpu/kv_smc.c (pass 2, beyond the known DF-2130 missing-smc_idx_lock finding — this defect is independent of the lock).

Root cause

amdgpu_kv_notify_message_to_smu() (kv_smc.c:33-55) posts a message to the Kaveri/Kabini/Mullins SMC microcontroller and then validates the response:

        for (i = 0; i < adev->usec_timeout; i++) {          /* :40 */
                if ((RREG32(mmSMC_RESP_0) & SMC_RESP_0__SMC_RESP_MASK) != 0)
                        break;
                udelay(1);
        }
        tmp = RREG32(mmSMC_RESP_0) & SMC_RESP_0__SMC_RESP_MASK;   /* :45 */

        if (tmp != 1) {                                     /* :47 */
                if (tmp == 0xFF)                            /* :48  Failed  */
                        return -EINVAL;
                else if (tmp == 0xFE)                       /* :50  UnknownCmd */
                        return -EINVAL;
        }

        return 0;                                           /* :54 — fall-through */

Per the SMC protocol, 0x01 = PPSMC_Result_OK, 0xFF = Failed, 0xFE = UnknownCmd (sys/dev/drm/amd/amdgpu/ppsmc.h:67-68), and 0x00 means "no response yet". When the wait loop exhausts adev->usec_timeout (SMC wedged/hung — precisely the condition the check exists for), tmp is 0x00; the nested if only rejects 0xFF/0xFE, so tmp==0 falls through to return 0 = success. Every undefined code in 0x02..0xFD likewise returns success.

Contrast with the CI sibling in the same driver: amdgpu_ci_send_msg_to_smc() (sys/dev/drm/amd/amdgpu/ci_smc.c:170-187) returns the raw response to its callers, so a timeout (0 ≠ PPSMC_Result_OK) is observed as not-OK. KV converts it to a silent success.

Impact

On an SMC that has stalled/timed out, every DPM operation (amdgpu_kv_smc_dpm_enable kv_smc.c:106-112, BAPM :114-120, the ~40 amdgpu_kv_copy_bytes_to_smc() table uploads from kv_dpm.c, force-level and get-enable-mask messages) is believed to have succeeded. The driver's PM state machine then proceeds on a dead controller — programming tables onto a wedged SMC, treating garbage reads as valid state (amdgpu_kv_dpm_get_enable_mask kv_smc.c:57-67 reads SMC_SYSCON_MSG_ARG_0 only because ret==0). Worst realistic outcome is PM state desynchronization → wrong clocks/voltage → GPU hang requiring reboot (local DoS); no kernel memory-safety consequence (the SRAM write path fails closed — see VERDICT.md). Trigger requires SMC misbehavior (hardware/firmware fault), not attacker input → Info (hardening / fail-closed correctness).

The radeon-driver twin sys/dev/drm/radeon/kv_smc.c:30-52 is byte-identical (same fall-through); noted here so the radeon side can be twin-filed.

Reproduce (static)

./check_static.sh

asserts, against the tree: (1) the exact fall-through structure at kv_smc.c:44-54 (no error return for tmp==0), (2) PPSMC_Result_OK == 0x01 so 0 cannot be a success code, (3) the ci sibling propagates the raw result.

Runtime reproduction requires Kaveri-class APU hardware with a wedged SMC; the QEMU audit guest has no AMD GPU at all (pciconf → 0 devices) — see VERDICT.md.

Fix

fix.diff — reject anything ≠ PPSMC_Result_OK:

-   if (tmp != 1) {
-       if (tmp == 0xFF)
-           return -EINVAL;
-       else if (tmp == 0xFE)
-           return -EINVAL;
-   }
+   if (tmp != PPSMC_Result_OK) {
+       dev_err(adev->dev, "SMC failed to handle message 0x%x (response 0x%x)\n",
+           id & SMC_MESSAGE_0__SMC_MSG_MASK, tmp);
+       return -EINVAL;
+   }

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.