A Linux kernel bug in AMD's graphics driver can let a local attacker crash your computer, and Microsoft has now weighed in with its own advisory. Tracked as CVE-2024-26672, the flaw lives in the amdgpu DRM driver and stems from a classic NULL pointer dereference. A local user with access to the GPU device node can trigger a kernel oops or panic, causing an immediate denial-of-service. The fix? A tiny code reshuffle that checks a pointer before it gets used. While the vulnerability spares bare-metal Windows, it directly threatens Linux environments—including Windows Subsystem for Linux 2 (WSL2) machines with AMD GPUs, Azure Linux VMs, and any dual-boot setup.

The U.S. National Vulnerability Database (NVD) rates this a high-severity issue, with a CVSS base score reflecting its low attack complexity and high availability impact. Distribution maintainers from Ubuntu to Debian have already shipped patched kernels. But if you run an AMD graphics card under Linux—whether on a Chromebook, a home server, or inside WSL2—you need to act.

The Flaw: A Pointer That Gets Checked Too Late

The bug lies inside the AMDGPU driver's Machine Check Architecture (MCA) SMU handling. Specifically, in the function amdgpu_mca_smu_get_mca_entry, the code assigns a function pointer mca_funcs from a device structure. It then dereferences this pointer to read fields like max_ue_count or max_ce_count—before ever verifying that mca_funcs isn't NULL. Only later does the code perform a NULL check. If the pointer happens to be NULL at that moment, the kernel dereferences memory at address 0x0. That's a guaranteed crash.

The mistake is as simple as it is dangerous: put the if (!mca_funcs) guard before any access, not after. The upstream fix, a one-liner in spirit, does exactly that. It was merged into the mainline Linux kernel and quickly backported to stable branches. Because the change is surgical and doesn't alter the driver's normal behavior on properly functioning hardware, it's an extremely low-risk patch.

Who's Affected? Not Windows, But—

If you're running a standard Windows desktop with an AMD GPU, this bug poses zero direct risk. The vulnerability lives inside the Linux kernel's DRM subsystem, which Windows does not use. However, the moment you introduce Linux into the equation, the picture changes.

  • WSL2 with GPU passthrough: WSL2 runs a real Linux kernel, and Microsoft enabled GPU acceleration for both NVIDIA and AMD cards. If you've configured WSL2 to use your AMD GPU (via wsl --install with the appropriate drivers), the Linux kernel inside the VM loads the amdgpu module. A process running inside a WSL2 distribution could theoretically exploit this bug to crash the entire WSL2 VM—and possibly your Windows session if the VM's crash ripples out. Microsoft's advisory explicitly acknowledges this as a supported scenario.
  • Azure Linux VMs: Microsoft's own Azure Kubernetes Service (AKS) and many Linux-based Azure workloads run on kernels that include the AMDGPU driver when AMD GPU-backed instances (like NVv4 series) are used. While GPU-accelerated VMs are often locked down, a successful crash could disrupt cloud-native applications.
  • Dual-boot and Linux-native systems: Any laptop, desktop, or server running an AMD GPU and a vulnerable Linux kernel can be crashed by a local attacker or a malicious process. Multi-tenant hosts (shared CI runners, university labs, container hosts) are particularly juicy targets because unprivileged users often have access to /dev/dri.

Attack prerequisites are low: an attacker only needs the ability to execute code on the machine and access to the GPU device file. On many Linux desktops, the default udev rules grant broad access to the GPU, and compositors like Gnome or KDE routinely open /dev/dri. A simple C program or a script that triggers specific DRM ioctls could weaponize this bug with near-certainty.

How We Got Here: Timeline of a Tick

  • 2 April 2024: The patch fixing the NULL pointer dereference lands in the upstream Linux kernel (commit ID not publicly listed in the sources, but confirmed by multiple advisories). It's a quiet fix; no one boasts about reordering a couple of lines.
  • Early April 2024: Stable kernel maintainers include the fix in their queues. Linux distributions start picking it up. Ubuntu, Debian, and Fedora ship updated kernel packages over the following weeks.
  • Late April 2024: The NVD publishes an analysis of CVE-2024-26672, classifying it as a high-severity local DoS. Other security trackers, including rapid7 and Amazon's ALAS, follow suit.
  • Present: Microsoft's Security Response Center issues its own advisory, highlighting the risk to WSL2 and Azure Linux. This is significant because it signals that even Windows administrators should care about a Linux-only CVE.

Microsoft's involvement isn't mere altruism. The company maintains its own Linux kernel fork for WSL2 and Azure Sphere. By publishing an advisory, it implicitly tells users to update the Linux kernel they get through Windows Update (if using WSL2) or to apply Azure-specific kernel patches.

Detection: Spotting an Attack

When the bug is triggered, the aftermath is unmistakable. Kernel logs (dmesg or journalctl -k) will show a NULL pointer dereference oops with stack traces that mention functions like amdgpu_mca_smu_get_mca_entry, amdgpu_mca_smu_get_mca_entry+0x1a/0x60, or other amdgpu_* symbols. The RIP register will point to address 0x0 or a very low offset from zero. The machine may hang, reboot immediately, or drop the graphics session entirely.

If you're running WSL2, things get murkier. A crash inside the WSL2 kernel may not produce a Windows blue screen, but you could see the WSL2 VM restart abruptly, lose all running Linux processes, or find error messages in the Windows Event Log under "Hyper-V-Worker". On Azure, the VM would become unresponsive and show a kernel panic in serial console logs.

To proactively check if you're vulnerable, run uname -r inside your Linux environment and compare the kernel version against your distribution's security advisories. For WSL2, the kernel version is something like 5.15.0-xx-microsoft-standard-WSL2. You can update it manually via wsl --update, or wait for a Windows Update that bundles a newer kernel.

Patch Now: The Fix Is a Reboot Away

The fix is trivial to deploy, and there are no reported regressions.

If you run Linux on bare metal or in VMs

  1. Update your kernel: Run your package manager's update command (apt update && apt upgrade, dnf upgrade, etc.) and reboot.
  2. Verify: After reboot, uname -r should reflect the latest kernel in your distribution's repository. For example, Ubuntu 22.04 users should look for a kernel version higher than 5.15.0-1xx (exact number depends on the advisory).

If you use WSL2 with an AMD GPU

  1. Update WSL2: Open a PowerShell or Command Prompt as Administrator and run wsl --update. This fetches the latest WSL2 Linux kernel from Microsoft.
  2. Restart WSL: Run wsl --shutdown and then restart your distribution.
  3. Check the kernel version: Inside WSL, uname -r should show a date stamp later than early April 2024. Microsoft typically releases updated kernels monthly, so the fix should already be included unless you've disabled automatic updates.

For Azure Linux VMs

  1. Apply Azure kernel updates: If you're using Azure-tuned kernels (like linux-azure), install the latest version via your distribution's standard mechanism.
  2. Reboot the VM: A livepatched kernel is unlikely to cover this bug; a full reboot is safest.

Mitigation: If You Can't Patch Immediately

Restricting access to the GPU device nodes can buy you time.

  • On Linux hosts:
  • Check current permissions with ls -l /dev/dri/*. If they allow world access (typical on desktops), tighten them. Create a custom udev rule (e.g., /etc/udev/rules.d/99-amdgpu.rules) that sets the group to something like video and removes world read/write permissions. Then add only trusted users to the video group.
  • For containers: do not mount /dev/dri into untrusted containers. Avoid --device=/dev/dri in Docker or similar flags in Podman unless the workload absolutely requires GPU access and is fully trusted.
  • On WSL2:
  • You can disable GPU passthrough by editing .wslconfig in your Windows user folder and adding [wsl2] gpuSupport=false. This will prevent any WSL2 distribution from accessing the GPU, but it will also break any GPU compute tasks. Use this only as a short-term stopgap.
  • On Azure:
  • If you can't patch, restrict network access to the VM, remove unnecessary user accounts, and monitor serial console logs for oops messages. Azure's host-level security boundaries prevent this from being a cross-tenant issue, so the threat is limited to inside the VM itself.

The Bigger Picture: AMD Driver Security Beyond Windows

This bug is a stark reminder that the security perimeter of a modern PC extends beyond Windows. Even die-hard Windows users now regularly spin up Linux VMs (for Docker, development, or testing), and Microsoft's tight integration of WSL2 means Linux kernel vulnerabilities can sometimes ripple into the Windows reliability experience. AMD has a dedicated security team, and its driver code is audited regularly, but the volume of kernel driver code makes mistakes inevitable.

For system administrators, CVE-2024-26672 reinforces three evergreen rules:
1. Update everything, not just Windows. The WSL2 kernel is a separate component with its own cadence.
2. Lock down GPU access on multi-user systems. If an unprivileged user can crash the host, that's a business risk—regardless of the OS.
3. Monitor kernel logs across your fleet. A spike in NULL pointer dereferences is often the first sign of an active exploit attempt.

Microsoft's decision to publish an advisory for a Linux-only CVE underlines how mainstream cross-platform security has become. For now, the fix is in, the patch is small, and the action is clear: update your Linux kernels and sleep better.