A refcounting bug in the Linux kernel's AMD display driver can crash your system or hand over local privileges—and it affects Windows machines with WSL2 or dual-boot setups. Tracked as CVE-2024-56775 and fixed in kernel 6.12.4, the flaw carries a CVSS score of 7.8. Microsoft's own advisory on the matter makes one thing clear: any Linux environment with an unpatched amdgpu driver is exposed, and that includes the kernel running inside Windows Subsystem for Linux 2.

The flaw: one slipped count, and the GPU driver unravels

The Direct Rendering Manager (DRM) inside the Linux kernel orchestrates access to graphics hardware. For AMD GPUs, the amdgpu driver uses reference counts (refcounts) to track plane resources—those hardware units that hold framebuffers and push pixels to your screen. Each time a plane is used, the refcount ticks up; when use ends, it must tick down. Get the count wrong, and you end up with memory leaks (objects never freed) or double-frees (objects freed while still referenced), both of which are recipes for kernel panics or worse.

CVE-2024-56775 lives in the code that backs up plane state and later restores it—a routine task during atomic mode changes or rollbacks. Before the fix, the backup/restore logic did not reliably capture the refcount. If another thread altered the count between backup and restore, the driver could end up with a refcount that was too high (leaking memory) or too low (enabling use-after-free or double-free). The upstream commit corrects this by caching the current refcount at backup time and re-applying it exactly during restore, closing the mismatch.

Who is affected, and what can an attacker actually do?

The bug is local—no remote network exploitation possible. But with low privileges (a local account with access to GPU device nodes, typically by being in the video or render groups), an attacker can trigger the flawed backup/restore path and cause system-wide instability. Reliable impacts include:

  • System crash or denial of service: Repeatedly corrupting memory can panic the kernel, taking down all services.
  • Memory exhaustion: Leaked kernel memory, if triggered in a loop, can make the machine unusable.
  • Potential privilege escalation: While no public proof-of-concept for code execution exists yet, kernel memory corruption of this type has been weaponized in the past. Modern hardening features like KASLR and SMEP raise the bar, but the risk is non-zero.

For Windows users, the vulnerability is not in the Windows kernel itself. Instead, the danger lies in the Linux kernel running inside WSL2 or on a dual-boot partition. If that kernel uses the amdgpu driver—and you have an AMD GPU—your WSL2 environment is at risk. The same applies to Linux virtual machines with GPU passthrough on Hyper-V or Azure.

What it means for your Windows ecosystem

WSL2 users with AMD graphics

In WSL2, the Linux kernel is delivered and updated via Microsoft. Recent versions include the amdgpu driver for GPU acceleration, which means if you run AI/ML workloads, graphical applications, or any compute that taps the AMD GPU, the driver is active. To exploit the flaw, a process inside your WSL2 instance (or a malicious container running there) would need access to /dev/dri/* device nodes. By default, only users in the video group can touch those devices; many distributions add the default user to that group for convenience. Check your own setup with ls -l /dev/dri/—if you see card0 and renderD128 with group video or render, and your user belongs to that group, the path is open.

Dual-boot setups

If you boot Linux natively on an AMD-powered machine, the vulnerability is a straightforward local threat. An unprivileged account that can interact with the GPU can destabilize the whole system. Multi-user workstations and lab PCs are prime targets.

Cloud and virtualized environments

Linux VMs with AMD GPU passthrough on Windows hosts inherit the guest kernel's vulnerabilities. Even if the host runs Windows and is itself immune, an attacker who compromises a VM with GPU access can crash that VM and potentially affect host stability through resource abuse. Cloud instances offering GPU acceleration with AMD hardware may also run vulnerable kernels unless patched by the provider.

How we got here: the bug's path into your kernel

The flawed backup/restore logic was introduced in the amdgpu display code long before the fix landed in kernel 6.12.4. As is common in the Linux kernel, the patch was first merged into Linus Torvalds' tree and then backported to stable kernels. Microsoft's Security Response Center (MSRC) issued its own advisory—an uncommon move for a Linux kernel bug—because of the direct impact on WSL2 and Azure services.

Major Linux distributors quickly incorporated the fix into their supported kernels. Ubuntu, Red Hat, SUSE, and Debian all released security updates that backport the patch to older kernel versions, meaning that the upstream version number (6.12.4) is not the only indicator of safety. A system running kernel 5.15 may already be patched if the vendor backport is installed.

What to do now: a patch-first approach

For WSL2 users

Microsoft ships a WSL2 kernel that is updated independently of Windows. To check your version, open a WSL terminal and run:

uname -r

Compare the output to the patched version. As of the fix, the latest WSL2 kernel provided by Microsoft includes the patch. Update WSL2 with:

wsl --update

Then restart the WSL instance (wsl --shutdown) and verify the new kernel is active. If the update is not yet available, or if you cannot update immediately, mitigate by restricting access to /dev/dri inside WSL. Edit /etc/udev/rules.d/99-restrict-dri.rules and add:

SUBSYSTEM=="drm", KERNEL=="card*", GROUP="trusted_gpus"
SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="trusted_gpus"

Then reload udev with udevadm trigger -s drm --action=add. Make sure your own user is not in the trusted_gpus group unless necessary. This will disable GPU acceleration for any process that needs the removed access, so weigh the usability impact.

For dual-boot or native Linux installations

Update your kernel through your distribution's package manager. Common commands:

  • Ubuntu/Debian: sudo apt update && sudo apt upgrade
  • RHEL/CentOS/Oracle: sudo yum update kernel
  • SUSE: sudo zypper refresh && sudo zypper update
  • Arch: sudo pacman -Syu

Reboot after installation. To confirm the fix is present, check your distribution's changelog or security advisory for CVE-2024-56775. Do not rely solely on the kernel version string.

For cloud VMs and multi-tenant environments

Ensure your cloud provider has applied host patches for GPU passthrough scenarios. For Linux guests, apply updates as above or deploy livepatch services if available (e.g., Ubuntu Livepatch, kpatch). Restrict container access to /dev/dri by never mounting it unless absolutely needed and only to trusted containers.

If you cannot patch immediately

  • Remove untrusted accounts from the video and render groups: gpasswd -d user video and gpasswd -d user render.
  • Tighten permissions on /dev/dri/* manually or via udev rules as described above.
  • Blacklist the amdgpu module as a temporary emergency measure by adding blacklist amdgpu to a file in /etc/modprobe.d/, but be aware that this disables all AMD GPU functionality—graphical sessions will fail or fall back to software rendering.

Outlook

The fix for CVE-2024-56775 is clean and effective, but the episode highlights a persistent challenge: kernel drivers are shared across all workloads, so a single refcounting mistake can ripple into Windows-adjacent systems like WSL2. Administrator attention should now turn to monitoring vendor channels for any sign of in-the-wild exploitation and to auditing which users and containers can touch GPU hardware. Microsoft's direct involvement in a Linux CVE advisory is a signal: the boundary between Windows and Linux security is thinner than ever, and hybrid deployments demand a unified patching strategy.