CVE-2023-52585

What it actually does

Possible NULL pointer dereference in amdgpu_ras_query_error_status_helper() when an invalid block id is supplied, because the code previously assumed the 'info' structure would always be non-null.

Why it matters to the business

On systems with AMD GPUs, an attacker with local access could trigger a kernel crash, leading to denial of service and potential loss of GPU-accelerated workloads until reboot.

How an attack unfolds

An attacker invokes the RAS error status query path with an invalid block identifier, causing the helper function to dereference a pointer that was never initialized, resulting in a kernel oops or panic.

How to fix it

Update the Linux kernel to a version containing commit 467139546f3fb93913de064461b1a43a212d7626 or later; apply the stable patch that returns -EINVAL for invalid block ids instead of proceeding with a potentially null info pointer.

How to confirm the fix worked

Confirm the running kernel contains commit 467139546f3fb93913de064461b1a43a212d7626; attempt to invoke the RAS query function with an invalid block id and verify it returns -EINVAL without crashing.

Typical attack path

1. Obtain local code execution or shell access on a Linux system using an affected AMD GPU driver
2. Trigger amdgpu_ras_query_error_status_helper with an invalid block id value
3. Kernel dereferences null pointer and panics

How to detect it

Review kernel logs for oops or panic messages containing amdgpu_ras_query_error_status_helper and references to line 1183 or the ras.c file; look for unexpected invocations of RAS query functions from user space.

What your security team should do

• Prioritize kernel updates on all AMD GPU systems within the next maintenance window
• Monitor for kernel oops reports referencing amdgpu_ras.c
• Restrict unprivileged local access on high-value GPU hosts until patched