CVE-2026-68238: Windows and Default WSL 2 Not Affected

The immediate practical audience is therefore narrow: Linux systems using the in-kernel

driver on hardware and firmware that expose a VFCT table, particularly machines running development kernels or distributions that take near-mainline graphics fixes. Standard Windows 10 and Windows 11 installations use AMD’s Windows display stack, not Linux DRM/AMDGPU, so they are outside the affected code path. Default WSL 2 installations are also unlikely to exercise it: WSL uses Microsoft’s virtualized graphics path rather than booting the guest directly against the host machine’s AMD ACPI firmware tables.

The NVD entry was published on August 11, 2026, but NVD was returning a Cloudflare 502 error when checked. That outage leaves the public record without the usual NVD analysis fields at publication time, including a usable severity assessment, affected-version range, and any exploitation discussion. The primary Linux patch and the mainline repository provide a much clearer picture of what this CVE actually fixes.

The leak occurs while AMDGPU reads firmware data​

Mario Limonciello submitted the underlying AMDGPU patch on July 8, 2026, under the title “drm/amdgpu: Release VFCT ACPI table reference.” The patch corrects

, a function in

that attempts to retrieve an AMD GPU’s VBIOS from the firmware-provided VFCT table.

VFCT, short for Video Firmware Configuration Table, is an ACPI structure supplied by system firmware. On systems where the AMDGPU driver can use it, the driver calls the ACPI subsystem’s

routine, parses the table for a VBIOS image matching the graphics device, copies that image into its own allocated memory, and continues device initialization.

The bug is that

acquires a reference to the ACPI table. The old AMDGPU code took that reference but returned from multiple success and error paths without calling

to release it. Limonciello’s patch routes those paths through a shared cleanup label that calls

before the function returns.

This is a resource-management defect, not evidence that the driver is copying attacker-controlled firmware into Windows or exposing a user-space buffer overflow. The leaked reference can keep the ACPI table mapped after the driver has finished inspecting it. The patch notes that the leak happens whether AMDGPU finds a matching VBIOS image or exits because the VFCT structure is malformed or truncated.

Linux mainline has the fix, but released kernels do not yet​

The fix was merged into the upstream Linux tree as commit

, authored by Limonciello. The mainline log shows it present before Linux 7.2-rc7, which was released on August 10, 2026. In other words, the source-level repair is available to users tracking the current development branch, but Linux 7.2 itself has not been released as a stable kernel.

That timing matters more than the CVE publication date. A CVE assignment does not put a patch into enterprise distributions, long-term-support kernels, appliance firmware, cloud images, or Microsoft’s WSL kernel. Those projects make their own backport and servicing decisions.

No Ubuntu Security Notice, Red Hat advisory, SUSE bulletin, or Microsoft WSL kernel release identified CVE-2026-68238 at the time of publication. The posted AMDGPU patch also does not carry a visible

request, which is commonly used to flag fixes appropriate for Linux stable backporting. That does not rule out later backports, but it means administrators should not assume the repair is already in a current 6.6, 6.12, 6.18, or vendor-maintained kernel merely because mainline has it.

The absence of a published affected-version range is especially awkward here. The vulnerable function predates this year’s kernel work by a wide margin: copies of

in older kernel trees already show the unpaired

call. The public patch fixes the leak but does not include a

tag identifying the exact introducing commit or the earliest affected upstream release. Until the CVE record is expanded or kernel maintainers publish stable status, claims that a particular distro release is patched should be treated as unverified.

The realistic impact is a kernel resource leak, not a remote compromise​

The strongest supported conclusion from the code is that this vulnerability can leak an ACPI table reference during AMDGPU initialization on affected systems. It is reasonable to classify that as a kernel resource leak; the primary patch says exactly that the mapping is leaked on every call after the table is acquired.

What the public materials do not establish is a remotely exploitable path, arbitrary code execution, privilege escalation, information disclosure, or persistent corruption. There is no public proof-of-concept, no CVSS score from NVD, and no vendor advisory describing attacker preconditions. Treating the identifier as a critical AMD GPU takeover issue would go beyond the available evidence.

There are limits to the reassurance. A resource leak in a kernel driver can become operationally relevant when the triggering path is repeatedly exercised. The normal AMDGPU VBIOS discovery sequence occurs during device initialization, so the practical concern is more likely to involve systems that repeatedly bind and unbind the driver, reload modules during testing, or repeatedly initialize affected hardware. A normal desktop user opening a graphical application does not cause AMDGPU to reacquire its VBIOS through VFCT on every frame or every login.

The table must also be present. Systems without a VFCT table do not reach the leak at all, because the function returns immediately when the ACPI lookup fails. And even with VFCT available, the driver must be using the AMDGPU path and attempt firmware-table VBIOS discovery. That is a narrower condition than simply “the computer has an AMD Radeon GPU.”

Windows and default WSL 2 are not the affected deployment​

For Windows users, the distinction is straightforward. CVE-2026-68238 names a defect in the Linux kernel’s DRM AMDGPU driver, located in Linux source code under

. Windows uses the Windows Display Driver Model and AMD’s Windows graphics driver packages. Updating Adrenalin Edition, Windows 11, or a motherboard BIOS specifically for this CVE is not supported by the evidence.

WSL deserves separate treatment because it runs a real Linux kernel, but the default configuration is still materially different from a Linux installation booted on the AMD machine. Microsoft ships WSL 2 with its own kernel builds; its currently published rolling-LTS releases are based on Linux 6.18, not the Linux 7.2 development line where the upstream fix landed. More importantly, a standard WSL 2 guest does not directly initialize the host Radeon GPU with native AMDGPU against the machine’s ACPI VFCT table. Its Linux graphics integration is virtualized and mediated by Windows.

There are exceptions worth checking. A user who has configured WSL to boot a custom Linux kernel, or who is testing native GPU-driver workloads in an unusual virtualized configuration, should inspect that custom setup rather than relying on the normal WSL assumption. For ordinary WSL users,

and

identify the installed kernel and servicing package, while

remains Microsoft’s supported route for obtaining the current WSL package.

What Linux administrators should do now​

Administrators with AMD GPU Linux hosts should inventory the kernel actually running before reacting to the CVE label.

identifies the loaded kernel, while package-manager history and the distributor’s security tracker show whether a vendor has incorporated

or an equivalent backport.

Systems following mainline Linux should update to a build containing the fix, then reboot into it. Systems on a stable or enterprise kernel should wait for the distribution’s advisory or confirm the specific patch in the vendor source package; moving a production host to an unreleased Linux 7.2 release candidate solely for this reference leak would be a disproportionate response.

For managed fleets, the more useful action is to mark CVE-2026-68238 as a Linux AMDGPU tracking item rather than a Windows endpoint emergency. Watch for the first stable backport or distribution bulletin, because that is the point at which version-based remediation can be made reliable. As of August 11, the concrete state is simple: upstream mainline contains the cleanup, NVD’s public page is unavailable, and no released-kernel remediation path has yet been documented.