CVE-2026-68112 Fixes Linux AMDGPU Kernel Panic Path

The NVD published the record on August 10, 2026, with no CVSS score, no CWE classification, and a two-sentence description from kernel.org: “There’s no need to crash the kernel for these cases.” The record identifies fixed kernels as Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and Linux 7.2-rc2 or later. That is the actionable part for administrators; there is currently no severity assessment to use in a conventional patch-priority calculation.

The underlying patch was included in AMD maintainer Alex Deucher’s July 2 pull request for the Linux 7.2 DRM fixes, then carried in the broader DRM fixes submitted for Linux 7.2-rc2. It was one of 13 AMDGPU changes in that pull set that remove or soften

and

behavior across multiple graphics and DMA engine generations. This CVE is therefore a newly assigned identifier for code fixed upstream weeks earlier, rather than evidence of a newly discovered active exploitation campaign.

The change prevents deliberate kernel termination​

In kernel code,

is an assertion with harsh semantics: if the condition evaluates true, the kernel treats it as a fatal internal error. On systems configured normally, that means an oops, a stopped workload, and frequently a full kernel panic or reboot depending on configuration.

records the unexpected condition and stack trace but permits execution to continue.

That difference is not cosmetic when the assertion can be reached from input that originates beyond a tightly controlled kernel path. A

may make sense for a condition considered impossible during early development, but it becomes a denial-of-service liability if a driver error, unusual job submission, corrupted state, or a user-influenced request can reach it on a deployed system.

Inspection of the pre-fix GFX 9.4.3 driver shows assertions around several command-stream and synchronization assumptions. They check that memory addresses are correctly aligned before the driver emits GPU packets: 32-bit addresses must be dword-aligned, while some 64-bit fence writes need qword alignment. Another assertion rejects an unsupported 64-bit fence flag in the kernel interrupt queue path.

The CVE description does not claim that an unprivileged local user can directly trigger those conditions. That omission is important. The new record is a reachable assertion style fix in the broad sense—removing a fatal response from driver code—but neither NVD nor the upstream commit message supplies a proof-of-concept, a triggering ioctl sequence, a privilege boundary, or a hardware-specific reproduction case. It should be treated as an availability-hardening fix with an unresolved exploitability assessment, not automatically as a demonstrated privilege-escalation flaw.

The NVD version range is broader than the source history​

The most conspicuous weakness in the current NVD entry is its version presentation. It lists affected versions beginning at

and extending until fixed releases in four maintained stable series: 6.6.148, 6.12.101, 6.18.42, and 7.1.6. Read literally, that could lead an asset scanner or dashboard reader to conclude that every historical Linux kernel is affected.

The CVE record itself carries a more precise source-level qualifier: the affected code is bounded by the introduction commit

and the five stable backports. That distinction matters because the vulnerable file and its GFX 9.4.3 support did not exist in every Linux release. The semver shorthand is useful to identify the corrected maintenance points, but it is a poor description of the vulnerable population.

For vulnerability-management teams, that means the right question is not “is the kernel below 6.6.148?” It is:

• Does this system run a kernel branch containing the GFX 9.4.3 AMDGPU implementation?
• Does the system load amdgpu and expose the relevant GPU functionality?
• Is its kernel older than the fixed maintenance update for its supported branch?

A Linux host running an Intel GPU, an NVIDIA proprietary driver, a software renderer, or AMD hardware handled through a different kernel driver does not become exposed merely because its kernel version falls inside NVD’s broad semver range. Conversely, an accelerator host with the relevant AMDGPU code should not wait for a CVSS number before taking the available stable update.

Five assertions, not a validation redesign​

The patch’s modest size also sets a limit on what it fixes. The pre-fix source contains assertions in the GFX 9.4.3 code for

packet emission, indirect-buffer submission, standard fence emission, and kernel-interrupt-queue fence emission. The patch changes the fail-fast behavior; it does not add new validation, reject malformed command streams earlier, or provide recovery logic for every bad alignment condition.

A warning is safer than a panic from the host-availability perspective, but it may leave an attempted invalid operation logged in

. The driver continues assembling the packet sequence after the warning. That is consistent with the upstream message’s narrowly stated goal—avoid crashing the kernel—but it should not be misread as an assurance that malformed internal state is harmless to the GPU job or the affected process.

This is also why the security impact should remain focused on availability. The available primary record does not describe memory disclosure, arbitrary memory write, privilege escalation, cross-tenant escape, or code execution. It describes the removal of crash-prone assertions. System owners should patch it because a kernel’s response to an anomalous driver condition should not be to take down the whole machine; they should not inflate the record beyond the evidence currently published.

Linux 7.2 and stable branches already contain the repair​

The upstream path is clear. Deucher’s AMDGPU pull request listed

as part of the fixes intended for Linux 7.2, and the subsequent DRM pull request for 7.2-rc2 retained it. Kernel.org’s CVE record says the original fix is present from Linux 7.2-rc2 and identifies stable backports for the maintained branches.

Administrators should use their distribution’s kernel package advisories rather than manually comparing Git hashes. The fixed upstream baselines are:

Those versions are upstream reference points, not a guarantee that every distribution package with a lower-looking version is vulnerable. Enterprise distributions routinely backport security fixes while retaining an older base version string. Red Hat, SUSE, Ubuntu, Debian, and appliance vendors may issue a patched kernel carrying their own release suffix; their changelog and advisory remain the authoritative package-level record.

For fleet operations, prioritize bare-metal GPU servers, shared compute nodes, graphics virtualization hosts, and systems allowing local users or containers to submit AMDGPU work. A desktop with an AMD card also merits its regular kernel update, but its operational consequence is typically a local session loss rather than interruption of scheduled compute jobs or multiple tenants.

Windows and WSL users do not patch this through AMD Adrenalin​

This CVE is in the Linux kernel’s

driver. It is not a Windows AMD display-driver advisory, and updating AMD Software: Adrenalin Edition on Windows does not remediate a Linux kernel assertion. Native Windows systems using AMD’s WDDM driver are outside the code path named in CVE-2026-68112.

Standard WSL GPU acceleration also should not be treated as direct evidence of exposure. Microsoft documents WSL graphics as GPU paravirtualization: guest-side interfaces communicate across the VM boundary to the Windows host’s graphics stack, while the physical kernel-mode driver runs on the host. Microsoft’s WSL guidance similarly directs AMD users toward the Windows vendor driver for DirectML-backed acceleration. That architecture differs from a Linux machine loading the physical

DRM driver named by this CVE.

The exception is straightforward: Windows administrators who run separate Linux virtual machines with direct GPU passthrough, or who operate Linux hosts alongside Windows endpoints, need to assess the actual Linux kernel in that environment. The relevant asset is the guest or host that loads

, not the Windows workstation used to administer it.

No public CVSS vector, exploit demonstration, vendor severity rating, or independent exploitation report was available when NVD published the record on August 10. The concrete consequence is still clear: systems on the affected AMDGPU path should move to their distribution’s kernel build incorporating Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, or the corresponding backport, so an unexpected GFX 9.4.3 alignment condition becomes a warning instead of a machine-wide outage.