CVE-2026-68364: Linux 7.1.6 Fixes AMDGPU Suspend Hangs

The National Vulnerability Database published the CVE on August 10, 2026, using kernel.org’s description and commit references. The Linux 7.1.6 changelog independently confirms that the stable release shipped the fix on August 3; Linux 7.1.7 and 7.1.8 have since followed. For users running their distribution’s own kernels, however, the important version is the vendor package version and its included backports—not merely the number printed by

.

The machine can hang before it has powered down​

This is a system-availability bug in

, specifically the AMD Display Core path used for display handling. The bad sequence requires two participants: the suspend path holds the display manager’s

and waits synchronously for delayed Idle State Manager, or ISM, work to finish; meanwhile, an ISM worker that is already running tries to acquire that same

.

Neither side can proceed. The suspend path cannot finish until the worker exits, and the worker cannot exit until suspend releases the lock. Kernel developers describe this as an ABBA deadlock: two execution paths obtain or wait on shared resources in opposite order.

The user-visible result is worse than a brief display flicker. A laptop can appear to enter suspend and then remain stuck; a desktop may blank its displays during shutdown but never actually power off. The stable-backport submission says CachyOS users reported that exact shutdown/reboot pattern on Linux 7.1 kernels: displays went dark, while the machine failed to complete power-down.

The affected code was introduced with AMD’s Idle State Manager work earlier in 2026. ISM was designed to rate-limit display idle optimizations through a finite-state machine and delayed work, reducing needless toggling of power-saving features. It also coordinates static-screen optimizations such as Panel Self Refresh and low-refresh Replay modes. That power-management machinery added asynchronous workers to a path that previously had fewer locking interactions during teardown.

In practical terms, this is most relevant to systems using the newer AMD display stack and kernels that include ISM. It is not a generic “all Radeon hardware hangs on suspend” finding, and the CVE record does not name a list of Radeon GPU generations, laptop models, APUs, or display-engine revisions. The affected files are confined to AMDGPU’s display manager and ISM implementation.

The repair changes lock ordering, not display policy​

The patch does not disable ISM, turn off AMD display power saving, or add a timeout that papers over a stuck suspend. It separates the old shutdown operation into two functions with deliberately opposite lock contracts.

First,

cancels queued ISM delayed work and waits for in-flight workers to finish. Crucially, it now must run without

held. This clears the scheduling side of the problem: a worker can take the display lock, complete its job, and let the suspend thread continue.

Second, a new

function returns each display controller’s ISM finite-state machine to

. That phase does require

, because it alters display state and can invoke the idle-optimization control path. By doing it only after worker synchronization has completed, the patch preserves the original end state without recreating the circular wait.

That division appears in three teardown-sensitive areas:

• Driver finalization before the display core is destroyed.
• The AMDGPU reset-specific suspend path.
• The normal display suspend path.

This wider placement is significant. The CVE title says “during suspend,” but the stable patch’s own notes connect the same locking flaw to suspend, shutdown, and reboot behavior. Administrators should therefore treat a shutdown hang after display blanking as potentially related, rather than assuming it is a firmware, systemd, or ACPI-only failure.

The repair also adds lock-dependency assertions. The disable function now explicitly asserts that

is not held, while the full-power function asserts that it is held. Those checks do not solve the issue by themselves, but they make a future regression in the locking contract easier to catch during kernel testing.

The CVE label should not be mistaken for an exploit advisory​

CVE-2026-68364 has no CVSS score, no CWE classification, and no published exploitation assessment as of August 11. The NVD record describes a kernel deadlock and availability failure; it does not claim that an attacker can execute code, elevate privileges, read memory, or cross a security boundary.

That distinction matters for patch triage. This is a real kernel CVE and a production reliability problem, particularly for laptop fleets, developer workstations, media systems, and remotely managed Linux endpoints that must reliably sleep, resume, reboot, or shut down. But the available record supports prioritizing it as a stability and availability fix, not treating it as evidence of a known remote compromise path.

The absence of a CVSS rating also means automated vulnerability platforms may display this issue inconsistently. Some will flag any CVE as urgent, while others may defer it because NVD enrichment is incomplete. The kernel’s own release record is more actionable here: Linux 7.1.6 contains the stable backport, and the current upstream release line has the equivalent fix.

There is a second limitation in the CVE metadata. NVD lists versions below 7.1.6 as affected and 7.1.6 through the 7.1 branch as unaffected, while separately identifying Linux 7.2-rc1 as the original upstream fixed point. That is useful for the upstream 7.1 stable series, but it does not establish the state of a distribution kernel.

Enterprise and long-term-support distributions routinely backport AMDGPU display changes and later fixes without adopting the matching upstream version number. Conversely, a distribution can carry a 7.1-derived package whose release string does not transparently identify every included stable commit. The published CVE also does not yet list downstream fixed package builds from Red Hat, SUSE, Canonical, Debian, or other vendors.

What Linux administrators should check​

The simplest immediate check for a self-built or vanilla-kernel installation is whether it is running Linux 7.1.6 or newer in the 7.1 series. Linux 7.1.8 was published on August 9, so systems tracking that branch should move to the newest available stable update rather than stopping at the first fixed point.

For distribution-managed systems, check the vendor changelog or security tracker for the package that supplies the running kernel. Look for the upstream subject

, the upstream commit beginning

, or the Linux 7.1 stable backport beginning

. A package carrying one of those changes has the relevant repair even if its kernel release string is not

.

Prioritize validation on machines that meet all of the following conditions:

• They use the in-kernel AMDGPU driver rather than a virtual display adapter or a system without AMD graphics.
• They run a kernel new enough to include AMD’s Idle State Manager changes.
• They have shown intermittent failures entering or leaving suspend, or shutdowns that blank the screen and stall.
• Their routine workload includes active video playback, video conferencing, browser video acceleration, or external-display activity before a suspend or reboot.

A controlled test should be mundane but repeatable: play hardware-accelerated video, allow the system to settle, suspend and resume repeatedly, then test reboot and shutdown. Capture

, AMDGPU messages, and any watchdog or lockdep reports after a failure. A successful update should eliminate the deadlock condition; it does not guarantee that unrelated suspend failures involving dock firmware, USB devices, wireless drivers, or platform ACPI are resolved.

The operational consequence is straightforward​

If an AMDGPU Linux system has been hanging with a black screen during suspend or getting stuck after display blanking on shutdown, updating to a kernel package that includes the Linux 7.1.6 backport is the concrete corrective action. The patch keeps the AMD display power-management feature in place and changes only the unsafe ordering between worker teardown and display-state locking.

The CVE was published after the stable fix had already shipped, leaving a short but important gap between remediation availability and vulnerability visibility. For organizations whose scanners only began flagging CVE-2026-68364 this week, the immediate task is to verify whether the existing kernel package already contains the backport before scheduling unnecessary emergency maintenance.