[PATCH AUTOSEL 6.19] drm/amd/pm: Fix null pointer dereference issue

Sasha Levin
2026-02-14T01:03:24Z

From: Jinzhou Su <jinzhou.su@amd.com>

[ Upstream commit 1197366cca89a4c44c541ddedb8ce8bf0757993d ]

If SMU is disabled, during RAS initialization,
there will be null pointer dereference issue here.

Signed-off-by: Jinzhou Su <jinzhou.su@amd.com>
Reviewed-by: Yang Wang <kevinyang.wang@amd.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:

## Analysis

### Commit Message Analysis

The commit message is clear and direct: "Fix null pointer dereference
issue." It explicitly states the trigger condition — when SMU (System
Management Unit) is disabled, during RAS (Reliability, Availability,
Serviceability) initialization, a null pointer dereference occurs. This
is a crash-inducing bug with a well-understood trigger.

### Code Change Analysis

The fix is a **3-line addition** in a single file
(`drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c`):

```c
if (!smu)
return ret;
```

This is added to `amdgpu_smu_ras_send_msg()`, which retrieves `smu` from
`adev->powerplay.pp_handle`. When SMU is disabled, `pp_handle` is NULL.
Without this check, the very next line dereferences `smu`:

```c
if (smu->ppt_funcs && smu->ppt_funcs->ras_send_msg)
```

This would cause a kernel oops/panic via null pointer dereference.

The return value in the NULL case is `-EOPNOTSUPP`, which is already the
initialized value of `ret` and is the appropriate error code for "SMU
not available."

### Classification

- **Bug type**: NULL pointer dereference (kernel crash)
- **Trigger**: SMU disabled + RAS initialization path
- **Fix type**: Defensive NULL check before dereference
- **Category**: Clear bug fix, one of the most common stable-worthy
patterns

### Scope and Risk Assessment

- **Lines changed**: 3 (adding a NULL check + early return)
- **Files changed**: 1
- **Risk**: Extremely low — the function already returns `-EOPNOTSUPP`
by default, so returning early with the same error code when `smu` is
NULL is completely safe and changes no behavior for the non-NULL case
- **Side effects**: None — callers already handle `-EOPNOTSUPP`

### User Impact

- **Who is affected**: Users with AMD GPUs where SMU is disabled (this
can happen in specific configurations or when SMU firmware fails to
load)
- **Severity**: Kernel crash (null pointer dereference → oops/panic)
during RAS initialization
- **Reproducibility**: Deterministic when SMU is disabled

### Stability Indicators

- **Reviewed-by**: Yang Wang (AMD engineer)
- **Signed-off-by**: Alex Deucher (AMD GPU subsystem maintainer)
- The fix is trivially correct — it's a standard NULL guard pattern

### Dependency Check

- No dependencies on other commits
- The `amdgpu_smu_ras_send_msg()` function exists in stable trees (it's
part of the AMD PM subsystem)
- Clean backport expected — the fix is self-contained

### Summary

This is a textbook stable backport candidate:
1. **Obviously correct**: Simple NULL check before dereference
2. **Fixes a real bug**: Kernel crash (null pointer dereference)
3. **Important issue**: Kernel oops during initialization
4. **Small and contained**: 3 lines in one file
5. **No new features**: Pure defensive fix
6. **Low risk**: Cannot break anything — only adds an early return for a
case that previously crashed

**YES**

drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index f51fa265230b3..2a0e826d0317d 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -618,6 +618,9 @@ int amdgpu_smu_ras_send_msg(struct amdgpu_device *adev, enum smu_message_type ms
struct smu_context *smu = adev->powerplay.pp_handle;
int ret = -EOPNOTSUPP;

+ if (!smu)
+ return ret;
+
if (smu->ppt_funcs && smu->ppt_funcs->ras_send_msg)
ret = smu->ppt_funcs->ras_send_msg(smu, msg, param, read_arg);

--
2.51.0