CVE-2026-68111 Fix Replaces Fatal AMDGPU GFX9 Crashes

The NVD published the record on August 10, 2026, from kernel.org’s CVE entry, with no CVSS score, CWE classification, exploitation status, attack vector, or privilege requirement assigned. The official kernel commit identified by the record is mainline commit

, subsequently carried into maintained stable branches. That absence of severity data is consequential: this is a real CVE with a defined fix, but it is not evidence of a documented remote-code-execution path or an in-the-wild campaign.

Five assertions were changed, and only five​

The terse CVE description says there is “no need to crash the kernel for these cases.” The associated Linux commit shows precisely what those cases are: five alignment checks in the GFX9 ring-emission paths now report a warning instead of executing a fatal

.

They cover:

• A memory-space address used by gfx_v9_0_wait_reg_mem() that is not dword aligned.
• GPU addresses used while emitting graphics and compute indirect buffers that are not dword aligned.
• Fence addresses that are not qword aligned for 64-bit writes or dword aligned for 32-bit writes.

The key point is that these checks were already reached after the driver had accepted values headed toward AMDGPU command submission. With

, a failed assertion could force a kernel oops or panic, turning a driver-side invariant violation into a host-wide outage. With

, the kernel records the condition and continues execution.

That change aligns with the Linux kernel project’s documented policy: developers are generally expected to use warnings and error handling rather than

-family macros, reserving fatal crashes for corruption or conditions where continuing is impossible. In this instance, AMDGPU maintainer Alex Deucher’s commit makes the maintainers’ conclusion explicit: these particular alignment failures do not justify crashing the operating system.

For a workstation, rendering node, or virtual desktop host using the in-kernel

driver, that is a meaningful resilience improvement. A malformed or unexpected command-stream condition should not automatically take every local session, service, VM workload, and remote connection down with it.

The fix suppresses the crash path; it does not repair bad input​

There is an important technical limit buried in the small diff. Each affected expression changes from an assertion such as

to

. The subsequent ring-write operations remain in place, and the commit does not mask alignment bits, reject the submission, reset the GPU, or return an error to userspace.

In other words, the patch changes the system’s response from crash immediately to log the fault and proceed. That is appropriate if the assumptions are diagnostic checks that should never be violated under normal operation and if the hardware or surrounding driver code can tolerate the result. But it does not establish that an underlying source of invalid alignment has been eliminated.

This matters when interpreting the CVE. The patch is best described as a kernel denial-of-service hardening fix, not as complete validation of command-buffer inputs. The NVD record does not identify a userspace application, a specific ioctl sequence, a container escape, or a hardware configuration that can reliably trigger the condition. It therefore cannot support the stronger claim that ordinary desktop users, remote attackers, or unprivileged local accounts have a proven exploit path.

There is also no published reproduction procedure in the CVE entry itself. Security teams should resist converting “AMD graphics driver” into a blanket high-severity finding without a vendor advisory or distribution assessment that defines affected hardware, access requirements, and practical trigger conditions.

The published patch is smaller than earlier public work on the same area​

The final mainline change is a ten-line edit: five removals and five additions. That is worth noting because an earlier April 2026 AMDGPU mailing-list patch from John B. Moore, with a closely related GFX9

-replacement subject, was much broader. That proposal converted or removed assertions across nine locations, added explicit error returns in some initialization paths, and in several alignment cases used

together with address alignment cleanup.

The stable CVE backports do not contain that broader recovery behavior. The final commit referenced by CVE-2026-68111 is limited to the five direct

to

substitutions. It does not alter the compute write-pointer logic, introduce

returns, or clear invalid low address bits before ring emission.

That distinction changes operational expectations. An administrator who updates to the fixed kernel receives protection from this particular fatal assertion behavior. They should not infer that every GFX9 assertion or every malformed AMDGPU submission path was revised in the same update. Several other AMDGPU

cleanup commits were included in the Linux 7.2-rc2 DRM fixes pull, spanning GFX8, GFX9.4.3, GFX10, GFX11, GFX12, several SDMA versions, and more. Those are separate code changes and should not be collapsed into CVE-2026-68111’s scope.

Fixed versions and the backport trail​

Kernel.org’s CVE data identifies these fixed stable releases:

The record lists the affected file as

and traces the vulnerable lineage back to commit

. That does not mean every AMD Radeon product is in scope. The affected component is the GFX9-specific implementation inside the upstream

kernel driver. Distribution maintainers may carry the patch under different package release numbers, so package version alone is not a reliable substitute for checking the distribution’s kernel changelog or source configuration.

For enterprise Linux fleets, the practical workflow is straightforward: determine the running kernel with

, identify whether the host has a GFX9-era AMD GPU using the in-kernel AMDGPU driver, and apply the distribution’s kernel update once it incorporates the relevant stable backport. Systems using vendor-maintained kernels, custom kernels, long-lived appliance images, or immutable host images need their own verification because they may not track the upstream version numbers directly.

The record also matters to Windows administrators running Linux workloads, but with a boundary. Windows itself and AMD’s Windows display driver are not affected by this Linux-kernel CVE. WSL 1 does not run a Linux kernel at all. WSL 2 does run a Microsoft-built Linux kernel inside a lightweight VM, but Microsoft documents that GPU access there is routed through the

device to the Windows GPU stack rather than through a conventional bare-metal AMDGPU setup. No Microsoft advisory currently ties CVE-2026-68111 to a WSL kernel release, so it would be premature to classify ordinary WSL 2 installations as affected merely because they use Linux.

panic_on_warn is the one material caveat​

Replacing

with

normally avoids an immediate fatal kernel path. But the Linux kernel documentation cautions that systems can be configured with

, a setting that promotes warnings into panics. On hosts using that policy, the behavioral benefit of this patch can be reduced or eliminated: an alignment warning may still become a system crash by administrator choice.

That setting is often deliberate in testing, kernel development, and some tightly controlled reliability environments, where stopping at the first warning is preferred to operating with potentially compromised state. Production administrators should know whether it is enabled before treating this update as a guaranteed availability mitigation.

CVE-2026-68111 should therefore be patched as a targeted AMDGPU kernel hardening issue, with expectations set correctly. The fixed kernels remove five unnecessary crash triggers in GFX9 ring handling. They do not provide a scored attack model, a published exploit, a universal Radeon product list, or a general cure for malformed GPU command submissions.