CVE-2026-68258: Linux AMD GPU CRIU Flaw Needs Kernel Fix

The CVE was published on August 11, 2026, but the public National Vulnerability Database page was returning a Cloudflare 502 Bad Gateway error at publication time. That outage leaves the usual NVD fields—CVSS score, affected-version list, CWE classification, exploit status, and reference set—unavailable. The primary upstream record is clearer: AMD kernel developer David Francis posted the fix on July 6, it was incorporated into AMD’s DRM fixes pull request on July 9, and it landed in the Linux 7.2 release-candidate line.

What the newly assigned identifier does not establish yet is just as important as what it does. There is no published severity rating, no public proof-of-concept, no report of in-the-wild exploitation, and no distribution advisory naming CVE-2026-68258 as of August 11. Administrators should patch it as a kernel security defect in a privileged GPU checkpoint-and-restore path, without inflating it into a remotely reachable Windows GPU flaw.

The missing check was inside CRIU queue restore​

The vulnerable code processes private queue data supplied during a CRIU restore operation. CRIU—Checkpoint/Restore In Userspace—is used to suspend an application, preserve its state, and later resume it, including in container migration or workload-recovery scenarios. AMD’s amdkfd implementation extends that process to GPU compute queues used by ROCm-class workloads.

The restore record contains two fields that matter here: a queue type and an

. An MQD, or memory queue descriptor, is hardware-facing queue state. Before the July fix, the restore routine checked that the broad input buffer fit within the user-provided data area, but it did not verify that the queue type was one of the kernel’s defined types or that the MQD length corresponded to the type of queue being restored.

That is a semantic-validation failure, not merely a missing total-length check. A malformed checkpoint could pass the generic size accounting while carrying a nonsensical queue type or an MQD length inconsistent with the queue implementation that would later consume it. The restore path then uses those fields to calculate where the MQD ends and the control-stack data begins, before passing the reconstructed state onward to queue creation.

The upstream patch adds an explicit

sentinel and rejects values at or above it. It also adds a helper that retrieves the expected MQD size from the active device queue manager for the declared type, then rejects any checkpoint record whose supplied

differs. Invalid data now returns

before it can proceed through queue restoration.

That change is narrow, but it closes the correct door: the patch validates that the checkpoint data describes a real queue in the form the selected GPU expects.

The fix is part of a larger amdkfd hardening cluster​

The patch did not arrive alone. Alex Deucher’s July 9 AMD DRM fixes pull request grouped it with three other amdkfd changes: bounds checking for CRIU restore event IDs, bounds checking when allocating an event-notification slot, and a change preventing buffer acquisition during CRIU queue restore. The Linux 7.2-rc3 change list carried all four.

That grouping is a useful warning against reading CVE-2026-68258 as a self-contained one-line bug. The relevant code path has been receiving attention because it reconstructs sensitive GPU state from userspace-provided checkpoint data. The amdkfd source itself describes CRIU operations as capable of loading arbitrary data into MQDs and, when hardware scheduling maps the queue, eventually into hardware queue descriptor registers. That is why those ioctl operations receive extra permission checks in the first place.

There is also historical context. The CRIU queue-MQD restore functionality dates back to AMD’s earlier ROCm checkpoint/restore work, and static analysis flagged an integer-overflow issue around restore-size calculations in 2022. That earlier problem concerned the sum of user-controlled control-stack and MQD lengths; the current code already performs that addition in a 64-bit type. CVE-2026-68258 addresses a different remaining trust boundary: whether the individual queue type and MQD length are valid for the target device.

The distinction matters for patch management. Seeing a 64-bit size calculation in a vendor kernel does not demonstrate that it contains this newer fix. Conversely, a kernel build may contain other CRIU hardening backports while still lacking the two checks introduced by this particular change. Track the commit or the vendor’s CVE advisory, not a nearby bug fix with a similar title.

CAP_SYS_ADMIN changes the threat model, but does not erase it​

The affected operation is not available to a normal desktop process by default. The amdkfd source marks the CRIU ioctl as requiring checkpoint/restore privilege and explains that older Docker behavior is accommodated by allowing

as well. A process must also be operating in an environment with the amdkfd compute driver, an accessible AMD GPU, and CRIU restore functionality in use.

That substantially narrows the exposure compared with a flaw reachable from a browser, media file, network packet, or ordinary game. A regular Linux user on an AMD desktop who is not using ROCm checkpoint/restore is not the target population for urgent disruption.

But

is often called “the new root” for a reason. It is commonly granted too broadly to privileged containers, GPU-enabled CI runners, development environments, and orchestration tooling. In a multi-user compute environment, the relevant question is not whether an attacker begins as an unprivileged Linux account; it is whether a tenant, container process, or automation service can invoke the AMD checkpoint/restore interface with elevated capabilities.

The best current reading is that CVE-2026-68258 is most relevant to systems that combine all of the following:

• They run a Linux kernel with amdkfd’s CRIU queue-restore support but without the July 2026 bounds-checking change.
• They expose AMD GPU compute to ROCm workloads rather than using the GPU only for desktop graphics.
• They permit CRIU restore activity or grant CAP_CHECKPOINT_RESTORE or CAP_SYS_ADMIN to workload-management software or containers.
• They operate shared, virtualized, or automated compute infrastructure where a malformed checkpoint may cross an administrative trust boundary.

A bare-metal workstation used for local ROCm development is still worth patching under normal kernel maintenance. A shared AMD Instinct or Radeon Pro compute host with privileged container workflows deserves a quicker review of who can restore workloads and which kernel package it is running.

Windows and stock WSL are outside the direct patch path​

For WindowsForum readers, the essential point is that this CVE concerns the Linux amdkfd kernel driver and its CRIU ioctl path. It does not identify a flaw in the Windows display-driver model, DirectX, Windows Hyper-V graphics virtualization, or AMD’s normal Windows Radeon driver.

AMD’s current ROCm-on-WSL documentation reinforces that separation. Its WSL support matrix lists the WSL2 Linux kernel 5.15 for supported Ubuntu guests, while its installation instructions use the WSL-specific package path with the

option. AMD’s WSL examples also expose the GPU through

, the WSL graphics interface, rather than asking users to build and load a mainline amdkfd kernel module in the guest.

In practical terms, updating AMD Adrenalin on a Windows 11 PC will not add the Linux 7.2 amdkfd validation checks, because it is not the component being changed. Likewise, a standard WSL ROCm installation should not be assumed vulnerable simply because it can run AMD compute workloads; its GPU path is architecturally different from a native Linux host using

.

The exception is custom infrastructure. Organizations running their own Linux kernel inside a virtual machine, a bespoke WSL kernel, or a Linux GPU-compute guest with direct AMD device access should inventory the guest kernel rather than relying on the Windows host’s patch level. The place to check is the Linux environment where amdkfd runs.

Kernel version labels are not enough yet​

Upstream placed the fix into the Linux 7.2 release-candidate stream. As of August 11, Linux 7.2 is still in pre-release testing, not a completed stable kernel series. Linux 7.1 remains the released upstream line, so production operators should not replace a vendor-supported kernel with a release candidate solely to obtain this correction.

That creates a short but real tracking gap. The upstream patch exists, while the public CVE record is not yet serving usable metadata and downstream distribution advisories have not yet established which packaged kernels contain a backport. A distribution can carry the fix in a kernel version numerically older than 7.2, or omit it until its next security update. The version string alone will not settle the question.

For now, the responsible operational response is straightforward: identify Linux hosts using AMD GPU compute and CRIU restore; restrict unnecessary

and checkpoint/restore privileges in containers; watch the kernel vendor’s advisory stream for CVE-2026-68258; and deploy the vendor kernel that backports the July amdkfd change. The upstream commit to match is

, titled “drm/amdkfd: Check bounds on CRIU restore queue type and mqd size.”