DF-5206 — trinity_acquire_mutex() cannot fail: silently proceeds without the SMC mutex on timeout

File: sys/dev/drm/radeon/trinity_smc.c:112-122 (+ all call sites in trinity_dpm.c) Severity: Info — hardware-reliability fail-open, unique to Trinity in the radeon SMC family (kv/si/ci/sumo have no equivalent void mutex-grant wait).

The defect

trinity_acquire_mutex() requests the SMC firmware mutex by writing 1 to SMC_INT_REQ (register 0x220, trinityd.h:167) and polls for the grant:

void trinity_acquire_mutex(struct radeon_device *rdev)   /* :112 — VOID */
{
    int i;

    WREG32(SMC_INT_REQ, 1);                            /* :116 */
    for (i = 0; i < rdev->usec_timeout; i++) {         /* :117 — up to 100 ms */
        if ((RREG32(SMC_INT_REQ) & 0xffff) == 1)       /* :118 */
            break;                                     /* grant */
        udelay(1);
    }
}                                                        /* :122 — timeout: silent return */

If the SMC firmware never grants the mutex (busy, wedged, or in a failure state), the function returns anyway after the 100 ms poll, without the mutex and without any way to tell the caller: the return type is void, so the failure is unreportable by construction. Every caller then programs SMC registers as if exclusivity vs the SMC firmware were held:

• trinity_dpm_enable_bapm — trinity_dpm.c:1099
• trinity_dpm_enable — trinity_dpm.c:1109
• trinity_dpm_late_enable — trinity_dpm.c:1138
• trinity_dpm_disable — trinity_dpm.c:1158
• trinity_dpm_set_power_state — trinity_dpm.c:1258
• trinity_dpm_setup_asic — trinity_dpm.c:1288
• (a 7th site at :1300 is inside #if 0 — dead code)

This mutex exists precisely to serialize the host driver against the SMC firmware's own accesses during DPM reprogramming; proceeding without it lets host register sequences interleave with SMC-internal ones → corrupted SMC register programs (clock/voltage/power-gating misprogramming). Reliability defect; no memory-safety primitive and no attacker-controlled input.

Why untested (see VERDICT.md)

Requires AMD Trinity hardware with an SMC that refuses the mutex grant. The audit QEMU guest has no radeon GPU; Info-class finding exempt from guest verification per the audit contract. fix.diff (API change: int return + -ETIME, all live call sites updated to bail out) is authored and git apply --check-verified, not hardware-validated.

Fix

fix.diff — trinity_acquire_mutex() returns int (0 on grant, -ETIME after backing off the request), prototype in trinity_dpm.h updated, and all six live call sites in trinity_dpm.c check the result and bail out.

DF-5206 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)

1. sys/dev/drm/radeon/trinity_smc.c:112 — void trinity_acquire_mutex(...). A void return means a failed SMC-mutex acquisition is structurally unreportable: no caller can ever know the grant timed out.
2. trinity_smc.c:117-121 — the grant poll runs at most rdev->usec_timeout iterations (100 ms, RADEON_MAX_USEC_TIMEOUT, radeon.h:131); on exhaustion the function silently returns at :122 with the mutex ungranted and the request line left asserted.
3. All six live call sites (trinity_dpm.c:1099,1109,1138,1158,1258,1288) proceed to program SMC registers immediately after the call, assuming exclusivity against the SMC firmware. The one remaining reference (:1300) is inside #if 0 dead code.
4. The kernel-side indirect-access race class (DF-2135) was checked and is NOT present on Trinity: tn_smc_rreg/tn_smc_wreg (sys/dev/drm/radeon/ni.c:41-58) hold rdev->smc_idx_lock for the TN_SMC_IND_INDEX/DATA pairs. What trinity_acquire_mutex arbitrates is host-vs-SMC-firmware serialization, which that lock does not cover — so the gap is real, not a duplicate of DF-2135/DF-2130.

Why not guest-verified

• Reachable only on AMD Trinity (HD 7xxx APU) ASICs; requires an SMC firmware that refuses/never grants the mutex (busy or wedged). The QEMU audit guest has no radeon GPU; no ioctl/sysctl/other software path reaches these functions — they run at DPM init/enable/disable/set-power-state from the driver's PM core.
• 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, attempts: 0, code_hash hashes analysis.txt.

Fix

fix.diff (3 files): - trinity_smc.c: int trinity_acquire_mutex() — returns 0 on grant, -ETIME on timeout after de-asserting the request and logging; - trinity_dpm.h:131: prototype updated; - trinity_dpm.c: all six live call sites check the result and bail (void functions return, int functions return -ETIME).

git apply --check verified clean against the pristine tree; never applied to sys/; not hardware-validated (fix_status: not_testable).

Escalation assessment

None. No memory-safety primitive; the defect degrades hardware PM sequencing only. No unprivileged input touches this path.

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.