CVE-2026-68115 Turns AMDGPU GFX10 Kernel Crashes Into Warnings

The newly published record, supplied by kernel.org and mirrored by the National Vulnerability Database on August 10, covers

. Alex Deucher’s AMDGPU patch series was posted to the AMD graphics mailing list on June 15, folded into the AMD DRM fixes pull request for Linux 7.2 on July 2, and later assigned the CVE identifier. That sequence matters: the code fix predates the public vulnerability entry by weeks, so distributions that backport DRM fixes may already carry it even where their package version does not match the NVD’s listed kernel release numbers.

Five fatal checks became warnings, and one was removed​

The source change is narrowly scoped: it replaces five

assertions with

calls and removes one

that rejected a 64-bit fence flag in the Kernel Interface Queue path.

The alignment assertions are in routines that write packets to AMD GPU command rings. They test whether an address is aligned on a 4-byte boundary for ordinary commands and, in one 64-bit fence case, on an 8-byte boundary. The checks cover a register-memory wait packet, graphics and compute indirect-buffer emission, and fence emission.

Before this patch, an unexpected value reaching one of those checks invoked

. In practical terms, the driver chose a fatal kernel failure over attempting to continue after detecting an invalid invariant. The patch changes those cases to

, preserving a diagnostic message while allowing execution to continue. The final change removes the check that prohibited

in the KIQ fence routine because the driver no longer considers that condition worth bringing down the host.

That is a meaningful resilience improvement, but it is important not to overstate what the patch does. WARN_ON() records that something went wrong; it does not repair the bad address or reject the operation. In the changed functions, the driver continues building the GPU packet after issuing the warning. The likely outcome is therefore a shift away from an immediate kernel crash toward whatever recovery, GPU fault handling, or downstream error the hardware and driver can manage.

The Linux patch description is blunt: “There’s no need to crash the kernel for these cases.” It does not say the underlying conditions became harmless, that they are reachable from an untrusted local application, or that they were being exploited. Those distinctions are absent from the CVE record and the patch discussion.

The CVE is about GFX10 code, not every AMDGPU installation​

The affected file is the GFX10 implementation in the in-kernel

driver. That is a much narrower population than “Linux machines with AMD graphics.” The same source file contains support for several GFX10-era IP versions, including Navi 10, Navi 12, Navi 14, Navi 21-class and Navi 22-class paths, as well as several integrated-GPU designs that use GFX10 graphics IP.

That said, mapping a retail Radeon product name to this driver file is not always straightforward. AMDGPU selects code based on graphics IP version and platform details, while a distribution may carry vendor backports that differ from mainline Linux. An administrator inventorying a fleet should establish both the loaded driver and the GPU’s reported graphics IP rather than use the CVE title as a blanket indicator for every Radeon device.

The vulnerability record’s machine-readable version range can also be misleading. Its affected Git range begins at

, the initial Linux Git commit, and runs to the backport-specific fix commits. That does not mean every Linux kernel since the repository began contained the vulnerable GFX10 code. GFX10 hardware support and

arrived many years after that initial commit. The lower bound is a record-format artifact rather than a credible introduction point for this specific defect.

For operational purposes, the real hardware boundary is whether the running kernel uses the GFX10 AMDGPU implementation, while the real software boundary is whether the distribution kernel includes the patch.

Fixed kernel releases are known, but package versions remain decisive​

The kernel.org CVE data names these first fixed stable releases:

• Linux 6.6.148.
• Linux 6.12.101.
• Linux 6.18.42.
• Linux 7.1.6.
• Linux 7.2-rc2 as the upstream baseline containing the original fix.

The record also references five distinct stable-tree commits, reflecting backports rather than five different vulnerabilities. That detail is useful when reviewing a vendor’s changelog: the relevant evidence is the presence of the GFX10

to

patch or one of its stable backports, not whether a package happens to use the exact upstream version string.

Enterprise distributions commonly ship long-term kernels with security and reliability fixes backported under a vendor-specific release number. A system reporting an older upstream base through

may therefore be patched; conversely, a custom kernel that advertises a newer-looking version may omit the commit. The distribution’s advisory, source package changelog, or kernel Git history is the authoritative answer for a managed deployment.

This also means there is no separate AMD Radeon Software package to update for the CVE on a standard Linux installation. The remediation belongs to the operating system kernel package. Systems using distribution kernels should apply the vendor’s current kernel update and reboot into it. Systems using self-built or appliance kernels should verify that the relevant stable backport has been applied to

.

No severity score means triage must follow the evidence, not the CVE label​

As published, CVE-2026-68115 has no NVD CVSS v4, CVSS v3, or CVSS v2 assessment. NVD also does not assign a CWE. The Linux kernel CVE entry supplies neither an attack vector nor prerequisites, privilege requirements, user interaction details, confidentiality impact, integrity impact, or a proof-of-concept.

No independent reporting located as of August 11 describes active exploitation or demonstrates that an unprivileged workload can intentionally drive these specific assertions. The patch itself arose as part of a broader AMD DRM cleanup that removed or softened fatal

and

paths across GFX8 through GFX12 and several SDMA implementations. The July AMD DRM pull request characterized that group as dropping unnecessary fatal checks from error paths, alongside unrelated display, memory, media, suspend, and GPU virtual-memory fixes.

That context argues against treating this entry like a conventional high-severity privilege-escalation advisory. It does not eliminate operational importance. A fatal assertion in a graphics driver can turn an anomalous condition into a host outage, which is especially undesirable on Linux workstations, GPU compute nodes, VDI hosts, and systems where a Radeon device provides the active console. But the public record presently supports a denial-of-service resilience concern, not a claim of code execution or data exposure.

Administrators should prioritize it according to the role of the GPU and the availability cost of a kernel crash. A shared workstation or compute host with affected GFX10 hardware merits normal prompt kernel patching. A single-user desktop can take the fix with its next routine distribution kernel update unless local policy requires immediate remediation. There is no evidence in the published record that emergency isolation, disabling AMDGPU, or removing a Radeon device is warranted.

Watch for warnings after updating​

The patch’s practical trade-off is diagnostic visibility instead of an unconditional crash. After deploying an updated kernel, administrators troubleshooting recurring graphics instability should watch

or the journal for AMDGPU warnings involving alignment, indirect buffers, waits, or fences. A warning is not a clean bill of health merely because the machine remains up; it is evidence that the driver reached a state the original authors considered impossible enough to enforce with a fatal assertion.

The immediate action is simple: update to a distribution kernel that includes the relevant stable fix, reboot, and confirm the running image rather than only the installed package. The longer-term consequence is more useful than the CVE’s sparse description suggests: systems that hit one of these AMDGPU invariants should now leave a kernel log trail for diagnosis instead of failing at the point of detection.