A recent Linux kernel vulnerability, CVE-2024-27042, was patched in the AMDGPU graphics driver code. This bug could allow an out-of-bounds access in the amdgpu_discovery_reg_base_init() function. While the code base seems complex, the root cause is a simple but dangerous logical slip: the code used an array index before checking that the index was valid.

In this post, we’ll explain what happened, show some code, and demonstrate a simple way attackers could have exploited it. We’ll also include official references and guidance on updating your kernel.

What is CVE-2024-27042?

CVE-2024-27042 is a bug in the AMDGPU driver (used by AMD graphics cards on Linux) where the code accidentally accessed an array before making sure the index was within the valid range. If untrusted user input (or faulty hardware) could set the index too high, the kernel would read (or potentially write) to memory it shouldn’t touch.

The bug was fixed in Linux kernel 6.9 rc1 and then backported further as needed.

Commit Reference

- drm/amdgpu: Fix potential out-of-bounds access in amdgpu_discovery_reg_base_init()

Where Was the Problem?

The function of interest is amdgpu_discovery_reg_base_init(); it sets up register base addresses for Video Core Next (VCN) engines on AMD cards.

The problematic code reads something like this

if (adev->vcn.vcn_config[adev->vcn.num_vcn_inst].max_mb_interface > ) {
    // Do something...
}

But the bounds check

- Should have made sure num_vcn_inst was less than the number of entries in vcn_config before using it as an index!

Why is this bad?

If num_vcn_inst was set (by accident or maliciously) to a value beyond the end of the array, the kernel would access memory that didn’t belong to the array (undefined behavior). In kernel-space, that can lead to escalated privileges, crashes, or worse.

How Was It Fixed?

The fix is simple but critical: Move the bounds check above the array access.

Old Code (Vulnerable)

if (adev->vcn.vcn_config[adev->vcn.num_vcn_inst].max_mb_interface > ) {
    // ...
}

Fixed Code (Safe)

if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES &&
    adev->vcn.vcn_config[adev->vcn.num_vcn_inst].max_mb_interface > ) {
    // ...
}

Now, if num_vcn_inst is out of bounds, the second line is never executed.

Demonstration: Minimal Exploit Concept

While this is kernel code, and not directly triggerable by most user programs, a badly written or malicious kernel module, or sometimes even userspace code manipulating particular sysfs/proc files, could have forced num_vcn_inst to a dangerous value.

Pseudocode Example

Suppose somehow adev->vcn.num_vcn_inst is set to 9999, but the array is only 2 elements long.

Vulnerable

// BAD: num_vcn_inst is not checked
uint32_t foo = adev->vcn.vcn_config[adev->vcn.num_vcn_inst].max_mb_interface; // Out-of-bounds!

Safe:

// GOOD: Check before access
if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) {
    uint32_t foo = adev->vcn.vcn_config[adev->vcn.num_vcn_inst].max_mb_interface;
}

Is this Exploitable?

- YES, in theory: If an unprivileged user can set or trigger a buggy num_vcn_inst, they could attack the kernel.
- In practice: Usually, this requires root or a kernel module, but sometimes mishandled IOCTLs (device control calls) or hardware errors expose paths for exploitation.

Technical References

- Upstream Patch Commit
- CVE Record at cve.org
- Discussion in Linux DRM Mailing List

If you use AMD graphics on Linux, update to a kernel including this patch (6.9 or backported).

- Use your Linux distro’s update utility, or check for security advisories mentioning “AMDGPU” and “CVE-2024-27042”.

Check your kernel

uname -r
# Search your distro security advisories for that version

Summary

CVE-2024-27042 is a classic but dangerous mistake: using an array index before checking it. Because it is in privileged GPU driver code, the consequences can be severe.

Update your systems, especially if you use AMD GPUs.

- Read the full commit diff for technical details.

Staying safe is a patch away!

*This explanation is made clear and easy for anyone interested in Linux security and is exclusive to this format. For more info, visit the references above or consult your system vendor.*

Timeline

Published on: 05/01/2024 13:15:49 UTC
Last modified on: 12/23/2024 19:12:55 UTC