CVE-2024-46871

What it actually does

Out-of-bounds array access in the AMD display driver caused by defining AMDGPU_DMUB_NOTIFICATION_MAX as 5 when the dmub_notification_type enum actually contains 6 values, allowing reads or writes beyond the bounds of dmub_callback and dmub_thread_offload arrays.

Why it matters to the business

Local attackers on Linux systems using AMD GPUs can achieve privilege escalation, arbitrary code execution, or kernel crashes, risking data theft, system downtime, and compliance violations; the issue affects the widely deployed Linux kernel ecosystem with high urgency for organizations running affected kernels.

How an attack unfolds

An attacker with local access crafts or triggers a dmub notification of the sixth type, causing the driver to index beyond the undersized arrays and corrupt adjacent kernel memory, which can be leveraged for code execution; listed threat actors have conducted similar Linux kernel out-of-bounds and uninitialized resource exploits in espionage and financially motivated campaigns.

How to fix it

Update the Linux kernel to commit e1896f381d27466c26cb44b4450eae05cd59dfd0 or later; Grafana users should upgrade to version 6.0.0-beta1+incompatible or newer if the component is present in their environment.

How to confirm the fix worked

Verify the running kernel contains commit e1896f381d27466c26cb44b4450eae05cd59dfd0; inspect the dmub_notification_type enum definition and confirm AMDGPU_DMUB_NOTIFICATION_MAX is set to at least 6; recompile and test display notification handling under load.

Typical attack path

1. Obtain local user or unprivileged process access on a vulnerable Linux system with AMD display hardware
2. Trigger or simulate a dmub_notification_type event that exceeds the declared maximum of five
3. Cause out-of-bounds read/write through the undersized dmub_callback or dmub_thread_offload arrays
4. Escalate privileges or execute arbitrary kernel code via memory corruption

How to detect it

Review kernel logs for out-of-bounds warnings or panics in amdgpu_dm or dmub paths; correlate with process activity that interacts with display or graphics subsystems; no widespread exploitation artifacts are known given the low EPSS and absence from KEV.

What your security team should do

• Immediately apply the referenced kernel commit or distribution backport on all AMD GPU systems
• Prioritize patching for internet-facing or multi-user Linux hosts given the local attack surface and high CVSS
• Monitor EPSS trend and threat actor activity for any increase in Linux kernel exploitation
• Harden local access controls and restrict untrusted code execution until patches are deployed