If you're working with Linux device drivers, especially with graphics or DRM (Direct Rendering Manager), you might have noticed a recent vulnerability — CVE-2024-46867. This issue affected the Linux kernel's drm/xe subsystem, specifically the memory information reporting for DRM clients. In this article, we’ll break down what the bug was, how it could be abused, what the patch fixes, and reasons you need to update your kernels.

What is CVE-2024-46867?

This CVE impacts the drm/xe/client.c code (Intel's modern GPU driver), where a deadlock and a "sleeping in atomic" bug were both possible in the show_meminfo() function.

The root of the issue is how the kernel code handles the destruction of buffer objects (BOs) during memory info reporting. If a buffer object put operation happens to drop the last reference, it will attempt to lock the same spinlock as the outer function — resulting in a potential deadlock, or even performing a sleep operation in an atomic context, which can crash your kernel or hang your system.

Original Commit

- Upstream commit reference
- CVE Details Listing
- Patchwork discussion

The bug existed in code like the following

// Simplified example of the bug pattern:
spin_lock(&client->bo_list_lock);
list_for_each_entry(bo, &client->bo_list, client_link) {
    // do stuff with bo
    xe_bo_put(bo); // <-- If this is the last reference, bo is destroyed here
}
spin_unlock(&client->bo_list_lock);

The problem: xe_bo_put(bo) might delete the object and even try to grab the *same* lock (bo_list_lock), causing a recursive deadlock or sleeping bug.

What’s wrong?

- Deadlock: By holding the lock and potentially acquiring it again, the process will lock itself out.
- Sleeping in atomic: spin_lock keeps you in an atomic context, but freeing a BO can sleep — breaking kernel safety guarantees.

Patch and Solution

The fix, merged and cherry-picked as commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a, switches to a safer deferred-release strategy:

Fixed Pseudocode

// Instead of directly putting (destroying) the buffer object inside the lock,
// defer the action and handle it outside.
LIST_HEAD(put_list);

spin_lock(&client->bo_list_lock);
list_for_each_entry_safe(bo, tmp, &client->bo_list, client_link) {
    xe_bo_get(bo); // take an extra ref
    list_add(&bo->put_link, &put_list);
}
spin_unlock(&client->bo_list_lock);

// Now safely put outside the lock
list_for_each_entry_safe(bo, tmp, &put_list, put_link) {
    xe_bo_put(bo);
}

Now the somtimes-blocking or recursive-free happens without the risk of locking bugs.

Reference Patch

See the actual patch diff.

How Could This Be Exploited?

A clever user-space program (or attacker) with access to DRM device nodes could deliberately hold and release references in a way that triggers this deadlock — for example, by rapidly opening/closing BOs (Buffer Objects) and querying memory info at the right time. This could:

- Hang/crash the kernel — Denial of Service (DoS)

Lock up graphics acceleration for all users

*There’s no direct privilege escalation path, but any kernel lockup is a severe impact on reliability and security.*

How to Identify and Mitigate

- Kernel version: If you run a custom or slightly older kernel with Intel XE/DRM enabled, *check your sources/modalities* for the inclusion of this patch.
- Update: Upgrade to a kernel version including or newer than commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a.
- User Access: Restrict /dev/dri/* if not needed by untrusted users.

Takeaways

- Even core Linux kernel code can have tricky concurrency bugs like this — especially in device drivers.

The deferred-release pattern (collect to a list, free after unlocking) is robust and often needed.

- Always keep your Linux kernels and modules up to date, especially on servers and desktops using modern Intel GPUs.

References

- Linux Kernel commit: drm/xe/client: fix deadlock in show_meminfo()
- CVE-2024-46867 on CVEDetails
- DRM/xe: Linux Graphics Documentation
- LKML Patchwork discussion

Conclusion

CVE-2024-46867 is a perfect example of why concurrency is hard, even in established projects like the Linux kernel. To stay safe, always update your kernels, especially if you use Intel GPUs or allow users direct DRM device access.

Let us know if you want further analysis or if you have questions about Linux driver security!

Timeline

Published on: 09/27/2024 13:15:17 UTC
Last modified on: 10/01/2024 17:09:58 UTC