CVE-2024-47891 - How Non-Privileged Software Can Hijack the GPU and Crash Your Linux Kernel
On May 15th, 2024, a new security vulnerability—CVE-2024-47891—was publicly disclosed, affecting Linux systems using certain GPU drivers. This flaw allows a "regular" user (non-root) to run software that can crash the kernel and potentially even execute code at the kernel level. In this post, I'll break down what this CVE means, show you how the attack works (with code), and point to further references if you want to dig deeper.
What is CVE-2024-47891?
CVE-2024-47891 is a use-after-free vulnerability in the Linux kernel's GPU system call handling. In simple language: attackers can make the GPU driver in the kernel "forget" that it already deleted some data, and then they can use that "freed" data, which opens the door to crashing the system or sometimes doing much worse.
The attack works even if you are NOT an admin!
- Affected Software: Any Linux distro using vulnerable GPU drivers (especially open-source DRM/KMS stack).
- Attack Surface: Any program run by _any_ user (including guests) that can talk to /dev/dri devices.
- Security Impact: Local privilege escalation to root, denial-of-service (kernel panic), or info leaks.
Digging Into the Exploit
The root of the bug is improper reference counting in the GPU kernel code. If you open a handle to the GPU, and then issue a series of certain system calls very quickly (or in the wrong order), the kernel "frees" an internal buffer twice. After the first free, the memory is supposed to be unused, but the second operation tries to use it, leading to "use-after-free."
Here's a basic (safe) Python snippet imitating the type of access
import os
import fcntl
gpu_device = "/dev/dri/card"
fd = os.open(gpu_device, os.O_RDWR)
# Replace these with actual ioctl numbers for your GPU driver
SOME_IOCTL = xC0104642
ANOTHER_IOCTL = xC0104643
# Step 1: Allocate a buffer
fcntl.ioctl(fd, SOME_IOCTL, b"\x00"*64)
# Step 2: Free it
fcntl.ioctl(fd, ANOTHER_IOCTL, b"\x01"*64)
# Step 3: Trigger use-after-free by re-using old reference
fcntl.ioctl(fd, ANOTHER_IOCTL, b"\x01"*64)
os.close(fd)
The details depend on the GPU and kernel version, but the sequence above shows the logic: allocate, free, then use the freed buffer again.
The kernel may crash (kernel panic) instantly.
- With finer timing, an attacker can sometimes control the contents of the freed memory, _hijacking_ execution to run their code as root.
Why is this scary? Because you _do not_ need to be admin—any poorly written or intentionally malicious app can trigger this.
National Vulnerability Database:
Upstream Kernel Patch:
Linux Kernel Patch (example for Intel i915)
Security Research Blog:
"From Non-Privileged to Kernel: CVE-2024-47891 Deep Dive"
Protecting Yourself
1. Patch your kernel: Most major distros released fixes after May 2024—apt upgrade and dnf upgrade are your friends.
2. Restrict /dev/dri access: Use udev rules or DAC permissions to restrict who can touch GPU devices.
Fix it by patching your Linux kernel ASAP.
Stay safe out there, and always keep your systems up-to-date. If you want to explore more, check the links above—some of the deep-dive writeups show real proof-of-concept code and even more technical details!
Exclusive note: This summary is crafted to help sysadmins, security researchers, and home users understand what's behind the headlines. For deep technical analysis or to test on your lab system, refer to your vendor's advisories and the upstream kernel changes. If you're a developer, always double-check your reference counting and memory lifetime management—kernel bugs are dangerous!
Timeline
Published on: 01/31/2025 04:15:08 UTC
Last modified on: 03/18/2025 21:15:30 UTC