CVE-2024-26797

What it actually does

The flaw permits an out-of-bounds array access in the map_hw_resources function inside the AMD display driver, allowing a local process to read or write beyond the bounds of dml2 scratch buffers and trigger a kernel buffer overflow.

Why it matters to the business

Systems running affected Linux kernels on AMD GPUs face elevated risk of crashes, data corruption, or local privilege escalation, potentially disrupting operations or enabling unauthorized code execution until kernels are updated.

How an attack unfolds

An attacker with local access supplies a display configuration that causes the index passed to map_hw_resources to exceed the declared size of the disp_cfg_to_stream_id and disp_cfg_to_plane_id arrays, resulting in memory corruption that can be leveraged for further kernel exploitation.

How to fix it

Upgrade the Linux kernel to a version containing commit 50a6302cf881f67f1410461a68fe9eabd00ff31d or later; rebuild and reboot with the patched kernel. Where live patching is available, apply the vendor's kernel live patch for this fix.

How to confirm the fix worked

Confirm the running kernel contains commit 50a6302cf881f67f1410461a68fe9eabd00ff31d via 'uname -r' and 'git log' or package metadata; recompile the dml2_wrapper module if custom builds are used and verify the bounds check is present in the resulting binary.

Typical attack path

1. Obtain local user access on a vulnerable Linux system with AMD display hardware
2. Craft or trigger a display pipeline configuration that sets an index value of 7 or higher
3. Invoke the map_hw_resources path during DML2 resource mapping
4. Trigger the out-of-bounds access to corrupt adjacent kernel memory
5. Escalate privileges or cause denial of service from the resulting corruption

How to detect it

Review kernel logs for smatch-reported buffer overflow warnings or oops messages referencing dml2_wrapper.c near map_hw_resources; correlate with unexpected display configuration changes or crashes on AMD hardware.

What your security team should do

• Prioritize kernel updates on all AMD GPU hosts within the next maintenance window
• Restrict local access and untrusted user workloads on systems that cannot be immediately patched
• Monitor vendor kernel update channels for backported fixes in supported LTS branches
• Include this driver path in future kernel fuzzing and static analysis runs