DF-4792 — vega20_smumgr signed table_id guard bypass (entry[] OOB read/write)

What

vega20_copy_table_from_smc() / vega20_copy_table_to_smc() in sys/dev/drm/amd/powerplay/smumgr/vega20_smumgr.c take int16_t table_id but the whole public API surface (hwmgr.h:218, smumgr.h:114, vega20_smc_table_manager at vega20_smumgr.c:563) is uint16_t. The only bounds check is a signed comparison:

PP_ASSERT_WITH_CODE(table_id < TABLE_COUNT, "Invalid SMU Table ID!", return -EINVAL);

Any API value in 0x8000..0xFFFF narrows to a negative int16_t, passes the guard, and indexes priv->smu_tables.entry[table_id] out of bounds (before the array — struct vega20_smumgr puts smu_tables.entry[] at offset 0, so entry[-1] reads the preceding heap object). The OOB .table pointer and .size then feed a memcpy in both directions = heap OOB read and write whose target/length come from adjacent kernel memory.

Pass-1 missed vega20; this is the exact family twin of DF-2021 (vega12), DF-2034 (vega10), DF-2072 (smu10) — all fixed the same way.

Reachability (honest)

Latent. Every in-tree vega20 caller passes a compile-time constant (vega20_hwmgr.c:760,1106,1234,1253,1310,1924,1958,2726,2735,2961 — TABLE_PPTABLE / TABLE_OVERDRIVE / TABLE_SMU_METRICS / TABLE_WATERMARKS). No sysfs/ioctl path forwards a user-controlled table_id. The bug becomes memory corruption the day any caller routes a 16-bit selector through smum_smc_table_manager() — exactly how the twins were rated.

Reproduce (inside the guest, after ./build.sh)

./build.sh   # builds df4792.baseline.ko (verbatim int16_t) + df4792.fixed.ko (fix.diff's uint16_t)
./run.sh     # kldload baseline -> kldunload -> kldload fixed -> kldunload

Expected console (dmesg) — baseline:

DF-4792 harness loaded (param type: int16_t)
DF-4792: in-bounds id=9 (unalloc) rc=-22 (want -EINVAL)
DF-4792: to_smc(0xFFFF) rc=0 victim[0..7]=4141414141414141 << CONTROLLED KERNEL WRITE
DF-4792: from_smc(0xFFFF) rc=0 victim[0..7]=4141414141414141 << OOB KERNEL READ
DF-4792: from_smc(0x8000 -> entry[-32768], far OOB) rc=-22

fixed (int16_t -> uint16_t, exactly fix.diff):

DF-4792 harness loaded (param type: uint16_t)
PP: Invalid SMU Table ID!
DF-4792: to_smc(0xFFFF) rc=-22 victim[0..7]=0000000000000000 (untouched)
...

The harness is a DragonFly KLD that compiles the verbatim function bodies (vega20_smumgr.c:163-236, 563-574) and struct layout (vega20_smumgr.h:29-43) with only the MMIO SMC-message sender stubbed to return 0 — see the header comment of vega20_oob_kld.c for the exact substitution contract. A groomed entry[-1] (32 bytes before the allocation, as on a real kzalloc(sizeof(struct vega20_smumgr))) supplies version=1, size=8, table=victim, so the OOB write/read land on a module-owned buffer — fully deterministic, no wild writes, no panic.

Fix

fix.diff — widen the two internal table_id parameters from int16_t to uint16_t (matching the public API), making the existing < TABLE_COUNT guard an unsigned comparison. Validated: harness-fixed variant rejects 0xFFFF/0x8000 with -EINVAL, and the patched TU compiles clean in the default -Werror kernel build (fix_build.log).

DF-4792 — VERDICT

Status: REPRODUCED (kernel-context harness; conditional primitive proven, latent reachability). Impact: none as shipped — no in-tree caller forwards an attacker-controlled table_id; the conditional primitive (any future caller passing a 16-bit selector) is a kernel heap OOB read and write, proven live in-kernel below. Confidence: certain.

1. The bug (source trace)

• sys/dev/drm/amd/powerplay/smumgr/vega20_smumgr.c:163-164 — vega20_copy_table_from_smc(struct pp_hwmgr *hwmgr, uint8_t *table, int16_t table_id) (signed)
• sys/dev/drm/amd/powerplay/smumgr/vega20_smumgr.c:170-171 — the only bound check: PP_ASSERT_WITH_CODE(table_id < TABLE_COUNT, "Invalid SMU Table ID!", return -EINVAL);
• sys/dev/drm/amd/powerplay/smumgr/vega20_smumgr.c:203-204, 210-211 — same in vega20_copy_table_to_smc
• PP_ASSERT_WITH_CODE(c,m,k) = if (!(c)) { pr_warn; k; } (inc/pp_debug.h:29-36) — a signed compare, so table_id == -1 passes.
• sys/dev/drm/amd/powerplay/smumgr/vega20_smumgr.c:172-175 / 212-215 — priv->smu_tables.entry[table_id].version/.size are then read OOB; :179/184 use the OOB .mc_addr; :192-193 / :217-218 memcpy with the OOB .table pointer and .size length — heap OOB read (from_smc) and write (to_smc).
• The narrowing entry point is in-tree: vega20_smc_table_manager(..., uint16_t table_id, ...) (vega20_smumgr.c:563-565) calls both copy functions with the uint16 → int16 implicit conversion (:569/:571), and the public API contract is uint16_t (inc/hwmgr.h:218, inc/smumgr.h:114).
• struct vega20_smumgr { struct smu_table_array smu_tables; } with entry[] the first member (vega20_smumgr.h:37-43), TABLE_COUNT=10 (inc/smu11_driver_if.h:837) → negative indexes land in the heap chunk preceding the kzalloc'd backend (vega20_smumgr.c:386).

Family: identical pattern already filed for vega12 (DF-2021), vega10 (DF-2034), smu10 (DF-2072) — all with the same int16_t→uint16_t fix. Pass 1 missed vega20; found in this pass-2 audit.

2. Reachability (why impact=none today)

All vega20 smum_smc_table_manager callers pass constants: vega20_hwmgr.c:760 (TABLE_PPTABLE), :1106/:1234/:1253/:1310/:2726/:2735 (TABLE_OVERDRIVE), :1924/:1958 (TABLE_SMU_METRICS), :2961 (TABLE_WATERMARKS). vega20_set/get_activity_monitor_coeff (vega20_smumgr.c:238-293) index with the constant TABLE_ACTIVITY_MONITOR_COEFF; workload_type only rides inside the SMC message parameter (| (workload_type << 16)), never a kernel index. No sysfs/ioctl/debugfs path forwards a user-controlled 16-bit table_id. So: latent defense-in-depth-against-future-callers — same rating as DF-2072 (Medium/memcorrupt).

3. Reproduction (guest, DragonFly 6.5-DEVELOPMENT, cc 8.3)

KLD harness vega20_oob_kld.c (see README for the verbatim-extraction contract): allocates a vega20_smumgr with 32 groomed bytes before it (modeling the preceding slab object), arms entry[-1] = {version=1, size=8, table=victim}, then calls the extracted vega20_smc_table_manager with the runtime value 0xFFFF (volatile, as it would arrive via the uint16 API).

Baseline (verbatim int16_t) — decisive lines from run.log:

DF-4792 harness loaded (param type: int16_t)
DF-4792: in-bounds id=9 (unalloc) rc=-22 (want -EINVAL)      <- guard fine for valid ids
DF-4792: to_smc(0xFFFF) rc=0 victim[0..7]=4141414141414141 << CONTROLLED KERNEL WRITE
DF-4792: from_smc(0xFFFF) rc=0 victim[0..7]=4141414141414141 << OOB KERNEL READ
DF-4792: from_smc(0x8000 -> entry[-32768], far OOB) rc=-22   <- far-OOB window exists too

• 0xFFFF → int16_t -1 → -1 < 10 true → entry[-1] consumed; the groomed .table=victim, .size=8 produce a controlled 8-byte kernel write of 0x41 bytes, and the function returns 0 (success).
• Read path symmetrically copies 8 OOB-sourced bytes out.
• 0x8000 (→ −32768) shows the window is the whole 32 KB before the object, not just one entry (here it landed on zeroed memory and was rejected by the version check — on a live system that is adjacent-kernel-memory-dependent).

Fixed variant (build.sh seds the harness's TID_T to uint16_t, i.e. exactly fix.diff):

DF-4792 harness loaded (param type: uint16_t)
PP: Invalid SMU Table ID!
DF-4792: to_smc(0xFFFF) rc=-22 victim[0..7]=0000000000000000 (untouched)
DF-4792: from_smc(0xFFFF) rc=-22 victim[0..7]=0000000000000000 (untouched)
DF-4792: from_smc(0x8000 -> entry[-32768], far OOB) rc=-22

All negative ids now rejected before any array access; in-bounds behavior unchanged. Baseline reproduced on 4 independent loads (see run.log history).

4. Why no uid=0 chain

The primitive triggers only on table_id ∈ 0x8000..0xFFFF reaching the copy functions; every in-tree vega20 caller passes constants. There is no unprivileged (or even privileged) syscall/sysfs path that forwards a user-chosen table id, so the escalation chain has no first link on a stock system. If such a caller ever appears, the chain would be: groom the heap chunk preceding hwmgr->smu_backend (kzalloc'd at vega20_smumgr.c:386, stable for the device's lifetime) → entry[-1].table = target, .size = length → copy_table_to_smc = arbitrary kernel write returning success.

5. Fix validation

• fix.diff: int16_t → uint16_t on both copy functions' table_id (vega20_smumgr.c:164, :204) — the guard becomes an unsigned compare.
• Harness-level: fixed variant rejects all negative ids (above).
• Kernel-level: applied to the guest's /usr/src copy and full make -j6 nativekernel KERNCONF=X86_64_GENERIC completed rc=0 with 0 error: lines in the default -Werror build (see fix_build.log); the patched vega20_smumgr.c compiled clean into the drm modules. Guest then reset (vm.sh reset with-src) — source tree reverted.

6. Honest notes / deviations

• Two early harness iterations panicked the guest — harness bugs, not the target code: (a) DragonFly's DECLARE_MODULE takes a moduledata_t struct, not a handler (garbage module name → strcmp GPF during kldload); (b) an uninitialized local hwmgr.smu_backend in the sanity probe. Both fixed; the final harness runs deterministically with no guest instability.
• GCC 8.3's -Warray-bounds independently flagged the exact OOB index during harness development when the trigger id was a compile-time constant (error: array subscript -32768 is below array bounds of 'struct smu_table_entry[10]') — the production TU escapes it only because table_id is a runtime parameter.
• No Vega20 hardware on the audit guest (QEMU) — the real driver never binds; hence the verbatim-extraction harness rather than a live-driver PoC.

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.