CVE-2026-68106 Affects Linux AMDGPU, Not Standard WSL

The Linux kernel security record, published August 10, identifies malformed frame dimensions below 16 pixels wide or high as the trigger. In the affected code, dividing those dimensions into 16-by-16 macroblocks produces zero; later H.264 decoded-picture-buffer calculations then divide by that zero value. The repair rejects sub-16-pixel frames before those calculations run.

That sounds like a small input-validation fix, and it is. But it is also a kernel-space crash condition in a graphics driver, which makes it a patching issue for Linux systems that expose an AMD GPU to the kernel and can reach the legacy UVD decode submission path. NVD currently provides no CVSS score, no CWE classification, and no exploitation assessment for CVE-2026-68106. It should be treated as a stability and defense-in-depth update rather than evidence of a confirmed in-the-wild attack campaign.

The affected code fails before the GPU decodes a frame​

The fault sits in

, not in a user-mode video player or the proprietary AMD graphics package for Windows. UVD is AMD’s older hardware video-decoding block, and the vulnerable kernel code handles H.264 decode-message validation and buffer sizing.

As described in the kernel CVE record, width and height are translated into macroblock counts. A dimension under 16 makes its corresponding macroblock count zero; multiplying those counts produces a zero frame-size value. The later computation of

in both the regular H.264 and H.264 performance decode paths then attempts a division using that zero value.

The fix is deliberately uncomplicated: it checks width and height before dependent calculations occur, rejects a frame where either dimension is below 16, and emits a rate-limited warning rather than filling logs repeatedly. That last detail came in the third revision of the patch and is operationally useful: malformed input should produce an actionable kernel diagnostic, not a flood of identical messages.

The result is a failed decode request rather than a kernel exception. It does not sanitize arbitrary H.264 content generally, fix a media-framework parser, or change normal-resolution playback. It establishes the minimum geometry the UVD H.264 path already assumed but had failed to enforce.

Linux stable fixes are available in four branches​

Kernel.org’s CVE data identifies fixed releases as Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6. The original upstream fix is recorded as landing in 7.2-rc2. Linux installations on an older point release in any of those stable series remain in scope until their distributor incorporates the applicable backport.

That version list is more valuable than the CVE’s broad “Linux” product label. It tells administrators not to mistake a major-version upgrade for the only path forward: the correction has been backported to supported stable lines. A system on 6.6 LTS does not need to jump to a 7.x kernel solely for this issue; it needs the vendor build based on 6.6.148 or newer.

Alex Deucher’s AMD DRM fixes pull request for Linux 7.2, published in early July, listed the UVD division-by-zero fix among a group of AMDGPU boundary-checking repairs. Dave Airlie subsequently confirmed that the wider AMD DRM-next pull had been merged. The patch was therefore in the upstream graphics tree weeks before CVE-2026-68106 received its public identifier on August 10.

That timing is worth noting for vulnerability-management teams. A CVE publication date is not necessarily the date code became available. Organizations that had already consumed a recent Linux 7.2-era graphics stack or the later stable backports may have been protected before scanners began flagging the identifier. Conversely, a scanner’s newly raised finding does not prove a newly introduced defect or a newly released patch.

WSL 2 uses a Linux kernel, but its standard GPU route is different​

Windows users should not map CVE-2026-68106 directly onto Radeon Software, AMD Adrenalin Edition, Device Manager, or a Windows cumulative update. Microsoft’s WSL documentation is explicit that WSL 2 runs a full Linux kernel, while its GPU-access documentation says GPU access in WSL occurs through

, which routes GPU calls to the Windows GPU stack. The WSL GPU path is based on GPU paravirtualization rather than handing a physical AMD adapter to the guest’s

kernel driver.

In practical terms, an ordinary WSL 2 install using GPU acceleration for Linux GUI applications, CUDA-like compute workloads, or graphics APIs is not automatically exercising the legacy UVD H.264 decode path named in this CVE. Microsoft’s GPU-paravirtualization design puts the Windows driver on the host side; the guest uses the virtualized interface. The CVE record does not claim that

,

, WSLg, or the Windows AMD driver is affected.

This is the important boundary the security record leaves unstated: the presence of an AMD Radeon GPU in a Windows PC is not enough to make a WSL instance vulnerable to this particular bug. There must be an affected Linux kernel, the

driver and UVD code available and used, and a route to submit the malformed decode description to that code.

The more plausible Windows-adjacent cases are customized environments: a Linux VM with direct AMD GPU assignment, a custom WSL kernel that loads and uses

, or a development/test environment built around native Linux video-decode interfaces rather than WSL’s standard virtual GPU path. Those environments need an inventory review; normal WSL GPU acceleration does not justify a conclusion either way from this CVE alone.

Microsoft’s newest published WSL kernel is still below the listed 6.18 fix​

There is, however, a patch-lag detail worth watching. Microsoft’s WSL2-Linux-Kernel release page currently lists

, released August 1, as its latest package. Kernel.org’s CVE record identifies 6.18.42 as the fixed stable point release. By version number, Microsoft’s current published WSL kernel package is two upstream stable releases short of the upstream fix.

That does not establish that standard WSL deployments are exploitable. As noted above, WSL’s usual GPU model does not equate to loading the affected AMDGPU UVD driver. It does mean that Microsoft has not yet published a WSL kernel release whose base version alone demonstrates inclusion of this upstream stable correction.

Administrators running custom WSL kernels should check the actual guest kernel with

, not merely the Windows build number or installed AMD driver version. Administrators of physical Linux workstations, VDI guests with GPU passthrough, render nodes, or media-processing appliances should compare their installed kernel package against the fixed versions and consult their distribution’s kernel changelog, since distributors frequently backport security repairs without matching upstream version strings exactly.

Microsoft recommends

for Store-delivered WSL updates, and keeping it current remains sensible maintenance. But as of August 11, updating WSL cannot be presented as a verified remedy for this CVE until Microsoft ships a kernel based on 6.18.42 or documents the backport.

Patch the Linux kernel where AMDGPU UVD is actually in use​

For Linux systems with AMD hardware video decoding exposed to the guest or host kernel, the action is straightforward: deploy the vendor kernel containing the fix. The relevant upstream baselines are 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with the change also present from 7.2-rc2 onward.

For Windows-only Radeon systems, there is no corresponding AMD Adrenalin or Windows Update action tied to CVE-2026-68106. For ordinary WSL 2 users, the item belongs on the WSL kernel watch list rather than in an emergency Windows-driver rollout.

The meaningful next milestone is a Microsoft WSL kernel package based on 6.18.42 or later, or a release note confirming the backport. Until then, the CVE’s real operational target remains Linux deployments where

UVD decode is present and reachable—not every Windows machine with AMD graphics.