CVE-2023-52673

What it actually does

Null pointer dereference in the AMD display driver debugfs code path when get_subvp_en() callback is absent and invoked without prior existence check.

Why it matters to the business

Kernel crashes or denial of service on Linux systems with AMD GPUs, causing unplanned downtime and potential data loss until systems are updated.

How an attack unfolds

An attacker with local access triggers debugfs operations on the AMD display subsystem to reach the unchecked callback invocation, resulting in a null dereference and system instability.

How to fix it

Upgrade the Linux kernel to a fixed version such as 6.7.3 or apply the patch corresponding to commit 43235db21fc23559f50a62f8f273002eeb506f5a (or 01e08e5d7656e660c8a4852191e1e133cbdb0a66) in the stable tree.

How to confirm the fix worked

Confirm the running kernel version meets or exceeds 6.7.3; inspect source for the added existence check on get_subvp_en() before invocation; test debugfs operations on AMD hardware post-update.

Typical attack path

1. Obtain local user access on a vulnerable Linux kernel with AMD display hardware
2. Interact with debugfs entries exposed by the AMD display driver
3. Invoke code paths that call the missing get_subvp_en callback
4. Trigger null pointer dereference leading to kernel panic

How to detect it

Search kernel logs and oops reports for entries referencing drm/amd/display and null pointer dereference or get_subvp_en; review debugfs access attempts in audit logs on AMD-based hosts.

What your security team should do

• Prioritize kernel updates to 6.7.3 or equivalent patched releases across all affected systems
• Review and restrict debugfs access where possible until patches are applied
• Monitor system stability metrics for AMD display-related panics during rollout