Re: [PATCH v2] drm/amdgpu: prevent parameter-space underflow in nested ATOM table calls

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/amdgpu: silent bypass of oversized ATOM table execution fails to abort
--

commit 6b59921539d22666969d301a49ef26fc67ab007b
Author: Aldo Ariel Panzardo <qwe.aldo@gmail.com>

drm/amdgpu: prevent parameter-space underflow in nested ATOM table calls

atom_op_calltable() invokes a child ATOM table, forwarding the parent's
parameter space with an offset. The previous logic mixed units (dwords vs
bytes) when subtracting the offset from the remaining capacity. This commit
fixes the unit mismatch by converting ps_shift to bytes.

> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c
> index 1a599d5cf6a5c..7db0118e654c0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -646,8 +646,8 @@ static void atom_op_calltable(atom_exec_context *ctx, int *ptr, int arg)
>  		SDEBUG("   table: %d (%s)\n", idx, atom_table_names[idx]);
>  	else
>  		SDEBUG("   table: %d\n", idx);
> -	if (U16(ctx->ctx->cmd_table + 4 + 2 * idx))
> -		r = amdgpu_atom_execute_table_locked(ctx->ctx, idx, ctx->ps + ctx->ps_shift, ctx->ps_size - ctx->ps_shift);
> +	if (U16(ctx->ctx->cmd_table + 4 + 2 * idx) && ctx->ps_shift * 4 <= ctx->ps_size)
> +		r = amdgpu_atom_execute_table_locked(ctx->ctx, idx, ctx->ps + ctx->ps_shift, ctx->ps_size - ctx->ps_shift * 4);

[Severity: High]
Does this code silently skip the table execution without aborting when the
parameter space request is oversized?

Looking at atom_op_calltable(), the variable r is initialized to 0. When
a child table requests an oversized parameter space where
ctx->ps_shift * 4 > ctx->ps_size, the new condition prevents the call to
amdgpu_atom_execute_table_locked(), leaving r as 0.

>  	if (r) {
>  		ctx->abort = true;
>  	}

This means the check above will evaluate to false, failing to abort the
interpreter. The parent table will continue execution assuming the child
table executed successfully, which could lead to using uninitialized
data or skipping critical hardware setup.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923152912.1296884-1-qwe.aldo@gmail.com?part=1