CVE-2024-50004

What it actually does

Mismatch in DCN35 DML2 policy causes bandwidth validation to acquire an unexpected DPP pipe, resulting in grey screen and system hang on affected AMD display hardware.

Why it matters to the business

Systems using certain AMD GPUs may experience unexpected display failures and full system hangs, leading to downtime and potential data loss in environments with high graphics workloads; low exploitability reduces immediate risk despite listed threat actor mentions.

How an attack unfolds

An attacker would need local access or a triggerable graphics workload to hit the misconfigured DML2 policy path; no public exploits or successful campaigns are associated, though generic Linux kernel threat actor references exist in reporting.

How to fix it

Update to fixed kernel commit 945dc25eda88b5d6e30c9686dc619ab981c22d0e or later; for Rocky Linux 8 dnsmasq packages apply 2.79-19.el8 or newer equivalent kernel updates containing the DML2 policy correction.

How to confirm the fix worked

Confirm kernel version includes commit 945dc25eda88b5d6e30c9686dc619ab981c22d0e; test display stability under load on DCN35 hardware after upgrade.

Typical attack path

1. Identify system with DCN35 hardware and vulnerable kernel
2. Trigger graphics or display operations that exercise DML2 bandwidth validation
3. Cause unexpected DPP pipe acquisition leading to hang

How to detect it

Review system logs for display driver errors or kernel hangs related to DML2 or DPP pipe allocation; check for unexpected system reboots following graphics activity.

What your security team should do

• Prioritize kernel updates on systems with AMD DCN35 hardware
• Monitor for grey screen or hang events in graphics workloads
• Apply patches within standard maintenance windows given low EPSS and absence from KEV