From: Guangshuo Li lgs201920130244@gmail.com
[ Upstream commit cc9a8e238e42c1f43b98c097995137d644b69245 ]
kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries.
Return -ENOMEM on allocation failure to avoid the NULL dereference.
Signed-off-by: Guangshuo Li lgs201920130244@gmail.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES - The patch adds a defensive check around the workspace allocation in `amdgpu_atom_execute_table_locked()`, returning `-ENOMEM` when `kcalloc(4, ws, GFP_KERNEL)` fails instead of leaving `ectx.ws` NULL while `ectx.ws_size` is non-zero (`drivers/gpu/drm/amd/amdgpu/atom.c:1248-1253`). This prevents the subsequent interpreter from walking a NULL pointer. - Without the change, the interpreter’s operand fetch path dereferences `ctx->ws[idx]` whenever a table accesses working-space entries (`drivers/gpu/drm/amd/amdgpu/atom.c:268-269`), so any allocation failure in the original code leads directly to a NULL-pointer oops during table execution. - `amdgpu_atom_execute_table()` is invoked across display, power, and firmware programming flows (e.g., `drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.c:235`, `drivers/gpu/drm/amd/amdgpu/atombios_crtc.c:101`), so the existing bug can crash the GPU driver during many user-visible operations under memory pressure; failing gracefully with `-ENOMEM` is far safer. - The fix is self-contained (one function, no ABI or behavioral changes beyond returning an existing error code) and mirrors established error handling elsewhere in the driver, so the regression risk is minimal while the payoff—eliminating a reproducible crash under allocation failure—is high. - No prerequisite features are involved, making the patch suitable for all supported stable kernels carrying this AtomBIOS interpreter; consider following up with the analogous radeon path, which shares the same pattern, to maintain parity.
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c index 427b073de2fc1..1a7591ca2f9a0 100644 --- a/drivers/gpu/drm/amd/amdgpu/atom.c +++ b/drivers/gpu/drm/amd/amdgpu/atom.c @@ -1246,6 +1246,10 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index, ectx.last_jump_jiffies = 0; if (ws) { ectx.ws = kcalloc(4, ws, GFP_KERNEL); + if (!ectx.ws) { + ret = -ENOMEM; + goto free; + } ectx.ws_size = ws; } else { ectx.ws = NULL;