AMD has quietly patched a kernel-level flaw in its Linux graphics driver that can crash your system or silently leak memory — and it’s triggered by something as mundane as plugging in an external monitor. The vulnerability, tracked as CVE-2026-31488, sits in the amdgpu driver’s handling of Display Stream Compression (DSC) and poses a genuine stability risk for anyone running Linux on an AMD GPU, especially with docking stations or multi-display setups.

The Bug That Confuses a Single Green Light for an All-Clear

The flaw resides in AMD’s Display Core (DC) code, the part of the driver that translates the kernel’s atomic display requests into actual hardware programming. During atomic commits — the transactions that bundle multiple display changes together — the driver runs a DSC pre-validation step to see if a stream’s compression timings have changed. If they haven’t, the code incorrectly clears a critical mode_changed flag on the CRTC (the hardware pipe that drives a display).

Here’s why that’s dangerous: an atomic commit often carries several independent updates at once. While one stream’s DSC timing might be stable, another part of the same commit could involve an entirely different mode change — like a panel reconfiguration triggered by hotplugging a monitor. By wiping the mode_changed flag, the driver essentially tells the later commit stages, “Nothing to see here,” even though a real transition is still pending. That broken signal then derails the careful object lifecycle management that keeps the kernel from leaking or misusing memory.

The downstream mess is twofold. First, because the CRTC appears unchanged, the driver skips releasing the old stream object, creating a memory leak. Second, it neglects to properly reference the new stream, leaving a dangling pointer. Later, when the system tries to tear down that stream, it writes through freed memory — a classic use-after-free that kernel memory sanitizers (KASAN) caught and that triggered this CVE in the first place.

Who Is at Risk?

If you use an AMD GPU on Linux and occasionally connect external displays, you are in the risk zone. The bug’s most realistic trigger scenario is a laptop with an internal panel and an external monitor connected via DisplayPort Multi-Stream Transport (DP-MST). When you dock, the kernel fires off an atomic commit that simultaneously reconfigures the internal panel (for instance, to switch its timing or resolution) and adds the external displays. The DSC validation path, seeing no compression change on the internal stream, then steals the mode_changed flag right out from under the other, unrelated mode transition.

Home users and power users

  • Symptom: Random graphics stack crashes, blank screens, or X/Wayland session resets when docking, undocking, or hotplugging monitors. The crash may not happen every time — it depends on the exact mix of mode changes in a single atomic commit. Occasionally, you might see unexplained memory pressure from leaked stream objects.
  • Why it’s sneaky: Users often blame window managers, compositors, or even the hardware itself. The bug’s handiwork can look like ordinary display flakiness, so it may linger unfixed on long‑lived consumer kernels.

Enterprise IT and admins

  • Availability threat: A driver crash on a managed workstation, thin client, or conference‑room PC is not just a cosmetic glitch; it can interrupt meetings, remote support sessions, or kiosk workflows.
  • Fleet diversity risk: The triggering condition depends on hardware topology, not just kernel version. A laptop that only ever uses its internal screen may never hit the bug, while the same model with a popular USB‑C dock could see it daily.
  • Patch lag: OEM and vendor kernels often trail mainline. If your fleet runs an older LTS kernel without the fix, those systems remain exposed until the next update cycle.

Developers and kernel hackers

  • Lesson in state machine hygiene: The bug is a textbook case of a validation shortcut crossing a conceptual boundary. If you work on DRM or display drivers, this CVE is a reminder that “no timing change” is not the same as “no mode change,” and that atomic state is sacred.

A Fix So Simple It’s Almost Invisible

The remedy, already merged upstream and tagged for stable releases, is beautifully minimal. In the pre_validate_dsc function, the driver now remembers the mode_changed value that existed before the CRTC was marked as DSC-affected, and restores it afterward instead of blindly setting it to false. No new heuristics, no risky inference about other possible mode changes — just a straightforward preservation of the bit that should never have been overwritten in the first place.

Why it works:
- Surgical precision: The change touches exactly the point where the bad logic lived, avoiding the risk of regressions that come from wider re‑architecting.
- Stable‑friendly: Its simplicity makes it a prime candidate for backporting, and indeed the CVE already sports stable‑backport tags.
- Truthfulness restored: The commit phase again sees the accurate state of the CRTC, so it correctly releases old streams and acquires new ones.

For those tracking kernels, look for updates that mention amdgpu, drm/amdgpu, or DSC pre‑validation in their changelogs. The fix does not alter any user‑visible behavior other than eliminating a rare instability.

How an Optimization Undid Display Safety

To grasp why this bug exists, you have to appreciate how Linux’s atomic display framework works — and how easily an optimization can break its contract. Atomic commits are not single‑item requests; they are transactions that may contain connector, CRTC, and plane updates, often mixed with bandwidth recalculations. The display manager validates the entire transaction against DRM’s state model, builds a corresponding hardware state, and then, only after everything checks out, applies it all at once. If any part of the validation mutates state in a way that erases the intent of a parallel change, the commit phase is left with a lie.

The trouble started with an earlier commit, 17ce8a6907f7, which introduced DSC pre‑validation into the atomic check path. The goal was innocent: avoid redundant work when a stream’s compression timing hasn’t really changed. But the implementation assumed that a no‑change result from one stream was enough evidence to clear the entire CRTC’s mode_changed flag. That assumption ignored a fundamental rule of atomic commits — a CRTC can have multiple, unrelated reasons to be marked as changed, and the DSC validation routine has no way of knowing whether those other reasons exist.

Real‑world display topology makes this more than a theoretical corner case. Modern laptops adjust panel behavior based on whether an external screen is present: resolution, refresh rate, HDR state, and panel‑self‑refresh logic can all shift simultaneously. An external DP‑MST monitor adds its own complexity, potentially triggering topology changes that affect other CRTCs. The AMD driver must keep each stream’s lifecycle consistent throughout validation and commit. Wiping a flag based on a single, narrow condition is a violation of that multi‑stream contract.

In essence, the optimization tried to say, “This stream’s DSC timing is fine, so we can forget about everything else.” The kernel, correctly, cannot forget.

What You Should Do Right Now

The fix is available; the task now is to get it onto your systems. Here’s a practical checklist:

For all users

  1. Check your kernel version. If you are running a mainline Linux kernel, look for version 6.13 or later (the fix was included in the 6.13‑rc cycle). For stable branches, watch for updates to 6.12.x, 6.6.x, 6.1.x, and 5.15.x that carry the backport. The exact sub‑version will vary; consult your distribution’s security tracker.
  2. Update promptly. On Debian/Ubuntu, run apt update && apt upgrade; on Fedora, dnf upgrade; on Arch, pacman -Syu. Reboot after the update to ensure the new kernel is active.
  3. If you can’t update immediately, consider avoiding dynamic display configuration changes on affected hardware. Hotplugging monitors, switching display modes, or toggling HDR may trigger the bug. This is a temporary workaround, not a long‑term solution.

For IT administrators

  • Audit your fleet. Identify all AMD‑GPU devices running Linux and check their kernel versions. Prioritize machines that regularly use docking stations or external monitors.
  • Monitor distribution advisories. Major distros (Ubuntu, Red Hat, SUSE) will publish updates with the CVE reference. Apply them through your normal patch management cycle.
  • Test the update. In heterogeneous environments, validate the new kernel on a sample of docking configurations before rolling it out widely. The fix is low‑risk, but a quick sanity test never hurts.

For developers

  • Instrument your testing. If you build custom kernels or modules, enable KASAN and the related kernel debug options. These tools helped catch the original problem and can guard against similar issues in your own code.
  • Audit for similar shortcuts. Search your driver’s validation routines for places where a local optimization might be overwriting broader transactional state. The rule: if you can’t prove that a flag‑clearing operation is safe for all concurrent changes, don’t do it.

Outlook: The Long Shadow of a Shortcut

The immediate crisis is contained. Distribution kernels are absorbing the patch, and within a few weeks, most up‑to‑date Linux systems will carry it. But CVE‑2026‑31488 leaves behind a more durable legacy: it exposes a class of validation error that could lurk in other display drivers and even in other parts of the AMD stack. The Linux graphics community is already alert to the pattern, and maintainers will likely scrutinize any code that conflates a single stream’s status with a CRTC’s atomic intent.

For users, the takeaway is clear: a display crash isn’t always a compositor bug or a loose cable. Especially with modern GPUs that layer compression, power management, and multi‑stream features onto every mode change, the kernel’s state machine must get every boolean exactly right. This fix ensures that AMD hardware does just that, so you can go back to docking and undocking without holding your breath.