CVE-2026-68245: Update Linux AMDGPU for PASID Race Fix

The NVD entry, sourced from kernel.org and published on August 10, 2026, currently has no CVSS score, no CWE classification, and no assessment from NIST. That is an important limit: the record establishes a real memory-lifetime defect and its fixes, but it does not establish a severity rating, a practical attack path, or evidence of exploitation. No public proof of concept or distribution advisory for this specific CVE was listed in the record at publication.

The supplied publication timestamp—August 11, 2026 at 01:15 Pacific time—falls on August 11 in UTC, while NVD labels the record as published August 10. The difference appears to be catalog timing or time-zone presentation rather than a competing disclosure date; kernel.org’s CVE change history records the entry arriving on August 10.

The race is between a PASID lookup and VM teardown​

The vulnerable function,

, receives a PASID, a process address-space identifier used by AMDGPU to associate GPU work with a particular virtual memory context. It looked up an

object in an xarray, then released the xarray lock and passed that VM pointer to

.

That sequence left a small but consequential gap. The pointer returned by

was valid only while the PASID xarray lock remained held. Once the code called

, another path could remove the VM’s PASID mapping and free the VM before the caller accessed

.

The March upstream patch from Fan Wu describes the race plainly: VM teardown removes the PASID mapping before freeing the VM, which is embedded in the owning file-private structure. If teardown ran after the lookup but before

was read, the kernel could access an object whose lifetime had ended.

The CVE description calls this a “use after unlock” issue. In more conventional kernel security language, the practical concern is a use-after-free-style lifetime race: releasing synchronization protection turns a previously valid pointer into one that can no longer safely be dereferenced. Whether that becomes a crash, corrupted diagnostic data, or a security boundary issue depends on timing and on the surrounding allocator and workload conditions—details the current CVE record does not provide.

The patch changes ordering, not AMDGPU’s external interface​

The correction is deliberately narrow. Rather than returning an

pointer from a helper that unlocks internally, the patched

performs the PASID lookup and obtains a reference to

within the same locked section.

The new path does four things in order:

• It acquires the PASID xarray lock.
• It loads the VM associated with the supplied PASID.
• It copies vm->task_info and increments that object’s kernel reference count while the VM is still protected.
• It releases the lock and returns the now-reference-counted task_info object.

The obsolete

helper is removed because its contract was the source of the bug: it handed callers a pointer after dropping the lock that made the pointer safe to use. The patch is only 20 additions and 15 deletions in

, but it corrects a basic ownership rule rather than adding a defensive check after the fact.

This also explains why merely adding a NULL check would not have solved the problem. A VM pointer may be non-NULL when tested and still become invalid before its member is accessed. Taking a reference to the object the caller actually needs, under the lock that stabilizes the lookup, closes that window.

The CVE’s affected-version data is broader than the upstream bug history​

There is a material inconsistency in the published record that administrators should not ignore. The CVE’s structured affected-product data lists Git history beginning at

, Linux’s initial public Git commit, through the stable fixes. Read literally, that suggests an extraordinarily broad historical range.

But Fan Wu’s upstream patch carries a

tag for commit

, titled

. That is the code change identified by the patch author as introducing the faulty behavior. The CVE description itself also says the flaw stems from the helper that performs an unlocked return of the VM pointer—logic tied to the later task-info handling design, not Linux’s earliest releases.

In short, do not interpret the “version 0” range as proof that every old Linux kernel is vulnerable. The more useful technical boundary is whether a kernel contains the

task-info change and lacks the follow-up locking fix. The NVD record does not currently explain the mismatch or map the vulnerability cleanly to every maintained long-term branch.

That distinction is especially relevant to enterprise estates. A distribution may run an older-looking kernel release number while carrying selected AMDGPU backports, or it may ship its own patch set that has already fixed the race without matching one of upstream’s exact version strings. Conversely, a custom-built kernel based on an affected point in the source tree may remain exposed even if its package naming does not resemble upstream stable releases.

Linux desktops, workstations, and GPU compute hosts are the relevant systems​

This is a Linux kernel AMDGPU driver issue, not an AMD Windows Radeon Software advisory and not a Windows graphics-driver update. Windows systems are therefore not directly remediated by any action related to CVE-2026-68245.

For Windows administrators, the practical overlap is limited to Linux environments they operate: bare-metal Linux workstations, dual-boot systems, AMD GPU compute nodes, virtual-machine hosts with passed-through AMD GPUs, and Linux test environments. WSL installations ordinarily use Microsoft’s graphics virtualization path rather than the guest kernel’s native AMDGPU driver for the Windows desktop GPU, so this CVE should not be treated as a blanket WSL vulnerability. Organizations using a custom WSL kernel or direct AMDGPU hardware exposure should verify their actual driver configuration instead of relying on that general rule.

The vulnerable code works with AMDGPU virtual-memory state and PASID mappings. Those paths are more likely to be exercised on systems doing GPU-accelerated compute, ROCm workloads, virtualization, debugging, or frequent process and GPU-context churn than on a lightly used desktop. That is a reason to prioritize patching GPU-enabled Linux infrastructure, not evidence that ordinary graphical desktop use is safe or that the flaw is remotely reachable.

What administrators should verify now​

Start by checking the kernel that is actually booted, rather than the package version merely available in a repository. On most distributions,

establishes the running kernel release, while the package manager and distribution security tracker establish whether the vendor has backported the AMDGPU patch.

Upstream’s published fixed points are Linux 6.12.101, 6.18.42, and 7.1.6. A system already running one of those releases—or a later release in the same upstream line—contains the stable fix. Linux 7.2-rc3 is identified as containing the original upstream correction.

For any other line, particularly vendor-maintained enterprise kernels, the release number alone is not enough. Check the distributor’s kernel changelog for CVE-2026-68245 or the AMDGPU PASID task-info lookup race, and inspect the source or patch list where no advisory exists. The kernel.org record names four stable commits, but it does not yet provide a distribution-by-distribution status list.

The current record gives security teams a clear patch target but leaves its real-world severity unscored. Until NVD or Linux distributors add an assessment, the responsible posture is straightforward: treat this as a kernel memory-lifetime correction in the AMDGPU driver, update affected GPU-enabled Linux systems through normal kernel maintenance, reboot into the patched kernel, and avoid inflating an unscored race condition into a confirmed privilege-escalation or remote-code-execution claim.