# DF-2072 PoC — SMU10 signed table_id OOB (latent / sibling of DF-2021/DF-2034)

## Status: VERIFIED (source-only) + FIX VALIDATED

`smu10_copy_table_from_smc`/`_to_smc` take `int16_t table_id`
(`smu10_smumgr.c:116/144`) while their public API contract is
`uint16_t` (`smumgr.h:114`, `hwmgr.h:218`, local wrapper at `:277`).
A caller passing `table_id=0xFFFF` narrows to `int16_t -1`, passes the
signed `table_id < MAX_SMU_TABLE(=2)` guard, and indexes
`priv->smu_tables.entry[-1]` OOB. `.size` controls memcpy length,
`.table`/`.mc_addr` control source/destination.

Latent: both SMU10 in-tree callers pass compile-time constants in
`[0,1]`. Same pattern as DF-2021 (vega12) and DF-2034 (vega10).

See `VERDICT.md` for the source trace and fix validation.

## Reproduce

```
./build.sh   # rebuilds the patched kernel (rc=0 with -Werror)
./run.sh     # source-only confirmation; no runtime PoC (latent)
```

## Fix

`fix.diff` widens the parameter type from `int16_t` to `uint16_t` in
both copy functions, matching the public API contract. The
`PP_ASSERT_WITH_CODE(table_id < MAX_SMU_TABLE, ...)` guard then operates
on an unsigned value, so `0xFFFF < 2` correctly fails.