CVE-2026-68273: Linux AMDGPU Patch Fixes P-State Race

The upstream patch by Intel engineer Tvrtko Ursulin describes the underlying defects plainly: AMDGPU’s context initialization path did not consistently take the lock that protects the active stable-performance-state context, even though sysfs controls and other context operations use that same lock. The result is a concurrency flaw in code that coordinates GPU clock and power-state overrides. AMD’s DRM maintainer Alex Deucher included the patch in the

pull request, and DRM maintainer Dave Airlie’s subsequent pull request lists it among fixes headed into the 7.2 cycle.

For Windows users, this is primarily a Linux and mixed-environment issue rather than a Radeon Software for Windows issue. Native Windows systems use AMD’s Windows display driver stack, not the Linux

kernel module. The systems that need attention are Linux workstations, dual-boot PCs, AMD GPU compute hosts, VM hosts with Linux graphics stacks, and custom-kernel deployments where AMDGPU is active.

The bug is in GPU power-state ownership, not ordinary rendering​

A P-state is a performance-and-power operating point. In this case, AMDGPU allows a graphics or compute context to request a stable state such as a peak clock profile, then return the device to its prior operating state when that context ends.

That seemingly narrow feature has shared state behind it. The driver tracks which context currently owns the stable P-state override through

, while system-level controls can also set GPU performance behavior through sysfs. The old code captured a context’s presumed restore state when the context was created, before it had actually taken control of the P-state.

That decision created two separate failures.

First, context creation read and acted on the shared context pointer without holding

. The patch calls out potential use-after-free and null-pointer dereference conditions during initialization because sysfs operations and context operations can modify or clear that pointer concurrently.

Second, a context that never changed the P-state could later tear down and restore an obsolete state anyway. More importantly, a context that did change the setting could exit after an administrator or management tool had made a newer sysfs-level performance choice. The old cleanup path could then overwrite that newer choice with the state remembered at context creation.

This is why the patch is more than a cosmetic cleanup. A crash is the obvious outcome of a null dereference or use-after-free, but silently reverting an administrator’s power policy is a distinct operational failure. On a GPU compute host, a job ending at the wrong moment could reset a performance profile selected for thermal, power-cap, validation, or workload-control reasons.

The upstream fix changes when state is saved and restored​

The fix does not merely add a lock around one read. It changes the ownership model.

Under the corrected logic, a context begins with no saved stable P-state. The driver saves the previous state only when that context actually takes ownership of the override for the first time. All transitions that inspect or change the owner run while holding the stable-P-state mutex.

At context destruction, the driver now restores the saved state only if the terminating context is still the registered owner of the active override. It then clears the ownership pointer while still under the same lock. If another actor has changed the state or taken ownership in the meantime, the departing context no longer gets to overwrite it.

That is the meaningful security repair: the driver establishes a single serialized authority over a shared pointer and ties restoration to verified ownership. The patch changes 71 lines in

, replacing an initialization-time snapshot with a state transition that occurs at the point of actual use.

The commit identifies

,

, as the introducing change. The patch also carries a stable-kernel notification marked

. That marker is important, but it is not the same thing as a confirmed distro rollout. It tells stable maintainers where the author believes the correction should apply; it does not establish that every Linux vendor has shipped a backport, nor does it identify fixed package builds.

What is known — and what the public CVE record still does not say​

The available upstream material confirms the bug class and the corrective code. It does not establish several details administrators normally expect from a finished CVE entry.

No usable NVD record was available when this article was prepared because the NVD host returned a 502 gateway error. As a result, NVD was not available to provide a CVSS score, weakness classification, formal affected-version range, CPE mappings, reference set, or an exploitation assessment. The submitted NVD snapshot gives a publication time of August 11, 2026, at 01:03:03 Pacific time, which is 08:03:03 UTC, but its “modified” field was still unknown.

There is also no public upstream advisory in the material reviewed that demonstrates remote exploitation, privilege escalation, or code execution. The kernel patch identifies potential use-after-free and null-pointer dereference paths, but those labels alone do not prove a practical escalation path. Treat this as a local kernel-driver vulnerability with an incomplete public severity record, rather than inflating it into a confirmed remote compromise issue.

The required race also matters to practical exposure. One side involves the GPU context and stable P-state machinery; the other involves system-level management through sysfs. On most conventional Linux installations, writes to device sysfs power controls require elevated privileges. That likely narrows the straightforward trigger conditions, though it does not remove the need to patch systems where privileged GPU management software and untrusted or semi-trusted GPU workloads coexist.

Windows and WSL administrators should separate the affected stack from the hardware​

An AMD Radeon GPU by itself is not the indicator of exposure. The affected component is the Linux AMDGPU driver, specifically its stable P-state context handling. A Windows 11 PC with an AMD graphics card and current AMD Adrenalin drivers does not load that driver and is not remediated by — or directly exposed through — this Linux kernel CVE.

WSL 2 also should not be treated as automatically affected. Standard WSL GPU acceleration is based on Microsoft’s virtualized GPU path and the Linux

driver rather than directly binding a physical Radeon device to the Linux AMDGPU module. A custom WSL kernel or unusual passthrough design is a different case, but ordinary WSL installations should verify their actual loaded modules before assigning this CVE to a Windows endpoint fleet.

The systems most likely to need action are easier to identify:

• Linux hosts where lspci -k shows a Radeon or AMD GPU using the amdgpu kernel driver should be reviewed against the distribution’s kernel advisory and package build.
• ROCm, Mesa, graphics-development, or render-node workloads deserve particular attention if they create AMDGPU contexts while automation also adjusts GPU power settings.
• Kubernetes, container, virtualization, and shared compute environments should be reviewed where GPU devices are delegated to workloads and a host-level agent manages clock or power policies.
• Dual-boot machines are only exposed while booted into an affected Linux kernel; the Windows installation on the same disk is a separate software environment.

Do not rely on

alone as proof of safety or exposure. Distribution kernels frequently carry backported fixes without adopting the newest upstream version number, while custom kernels may retain old driver code even under a newer-looking release string. The authoritative check is the vendor’s advisory or kernel changelog for the installed package build, followed by a reboot into the patched kernel.

Patch through the kernel channel, not the Radeon Windows driver channel​

The fix is in the kernel DRM subsystem, so the correct remediation route is a Linux kernel update supplied by the operating-system vendor, enterprise kernel provider, or managed appliance vendor. Administrators running self-built kernels should pull the upstream repair once it reaches the branch they maintain, then rebuild and reboot.

Until a fixed package is identified, organizations with tightly controlled GPU hosts can reduce unnecessary exposure by avoiding concurrent changes to AMDGPU stable-performance-state settings and workload context creation. That is a temporary operational precaution, not a substitute for the patched code: the bug lies in synchronization and state ownership inside the driver.

The immediate practical consequence is that Linux AMD GPU operators should begin tracking their kernel vendor’s handling of CVE-2026-68273 rather than waiting for the NVD page to become complete. Upstream has supplied a narrowly targeted fix, but the public CVE infrastructure was still failing at publication time and had not yet provided the version and severity data needed for automated vulnerability triage.