CVE-2026-64590: Microsoft Lists No Product or Fix

The available upstream record makes the omission more consequential. The named change began as a narrowly targeted two-line Linux graphics-memory fix for a DMA-API debug warning seen when a

buffer was imported by a DRM driver such as AMDGPU. It was later included in Linux 6.12.96 — and then another upstream developer identified that the change had removed a required cache-synchronization operation on the first CPU access to a buffer.

In plain terms, CVE-2026-64590 is not presently a conventional “install this Windows cumulative update” advisory. Microsoft has assigned the identifier, but has not explained whether it concerns Windows, WSL, Azure Linux, a Microsoft kernel package, or another product that carries Linux kernel code. Administrators should not assume an August Windows Update resolves it merely because the notice is hosted by MSRC.

The original issue was a Linux DMA debug warning​

The underlying patch, submitted by Mikhail Gavrilov in March 2026, changed the

driver in

.

allows user-space memory to be exposed as a DMA buffer, which can then be shared with graphics, media, and other hardware-facing drivers through the kernel’s DMA-BUF framework.

The reported symptom appeared with

enabled, a diagnostic kernel configuration. Importing a

into a DRM driver — the example used AMDGPU during video playback in GNOME Videos or Showtime — could produce a warning that cacheline tracking had encountered an

condition and that overlapping mappings were unsupported.

Gavrilov’s patch explanation says the warning occurred because two mappings of the same pages could coexist: one held by

for CPU-access handling and one created when a consumer such as AMDGPU imported the buffer. The debug subsystem saw mappings sharing cacheline boundaries and reported a potentially unsafe overlap.

The proposed remedy was to pass

during

and

. The rationale was that

already performs explicit cache synchronization when CPU access is requested through the DMA-BUF interface, making synchronization during every map and unmap redundant. The change also aligned

with established behavior in other DMA-BUF exporters, including DRM GEM and AMDGPU paths.

That is important context because the patch’s public purpose was reliability and diagnostic hygiene. The upstream submission did not describe remote code execution, privilege escalation, information disclosure, or an attacker-controlled crash. It was intended to stop a warning and avoid unnecessary cache-maintenance work.

Linux 6.12.96 carried the change before the later correction surfaced​

Linux stable maintainer Greg Kroah-Hartman announced Linux 6.12.96 on July 18, 2026, with the

change included. LWN.net’s release listing and the Linux 6.12.96 changelog both show the patch alongside another

correction: a fix for a DMA direction mismatch during buffer release.

That placement matters for distribution maintainers and organizations running long-term-support kernel branches. The commit was not left as an unmerged discussion patch; it entered an upstream stable release. Debian’s package tracking also shows Linux 6.12.96 entering its security update pipeline, which demonstrates the change’s movement into downstream packaging, even though the Debian notice does not single out CVE-2026-64590.

But the stable release should not be read as the end of the story.

On June 27, before the 6.12.96 release announcement, Collabora developer Robert Mader submitted a follow-up patch explicitly naming the

change as the regression source. Mader’s analysis found that the original patch’s assertion about redundant synchronization was incomplete: the first call to

may create the scatter-gather table and had previously relied on that creation path to perform cache synchronization.

After the original change added

, that first CPU-access path could proceed without the expected

operation. Mader’s proposed correction moves the explicit CPU-side synchronization so it occurs after the scatter-gather table has been obtained, including on the first access.

This is the discrepancy that the MSRC entry does not explain. The CVE title names the initial “skip redundant cpu sync” patch, but the upstream record shows that part of the supposedly redundant synchronization was not redundant. The later patch was specifically written to restore it.

Why cache synchronization changes the risk assessment​

DMA cache synchronization is not a cosmetic performance choice. On systems where CPUs and devices do not automatically observe the same memory contents coherently, the kernel must ensure that a CPU sees data written by a device and that a device sees data the CPU has prepared. A missing synchronization can result in stale data being consumed across that boundary.

The precise practical outcome depends on processor architecture, DMA implementation, buffer direction, and the drivers using the shared buffer. That is why it would be irresponsible to turn the public patch discussion into an unsupported claim of a working security exploit. No public MSRC text supplied with CVE-2026-64590 establishes one.

However, a CVE assignment to a change described as a debug-warning fix is a sign that the issue is being tracked as more than harmless log noise. The public documentation needs to identify the security property at stake, the affected code versions, and whether the later first-access synchronization correction is part of Microsoft’s remediation assessment. At present, it does none of those things.

The upstream record also shows why “the warning was spurious” is an inadequate closing diagnosis. The cacheline EEXIST warning itself may have been an artifact of the debug subsystem’s overlapping-mapping checks, but the attempt to suppress redundant synchronization exposed a distinct correctness problem in the first CPU access path. Those are related issues, not interchangeable ones.

What Windows, WSL, and Linux administrators can do now​

For Windows-only fleets, there is no Microsoft KB or Windows build guidance attached to CVE-2026-64590 in the currently available advisory material. There is also no public statement that native Windows is affected. Security teams should record the CVE as an unresolved vendor advisory rather than creating an emergency Windows Update deployment based solely on its MSRC listing.

For WSL users and administrators, Microsoft has not stated whether the WSL kernel is affected, whether the

facility is enabled in any supported WSL configuration, or whether a WSL kernel update contains either the original change or the proposed follow-up correction. The CVE therefore cannot yet be translated into a WSL version check.

Linux administrators have a more concrete, if still incomplete, path:

• Linux 6.12.96 includes commit 504e2b4ab97a, the change named in the CVE title.
• A later upstream patch from Robert Mader identifies that commit as needing an explicit first-access cache synchronization correction.
• Administrators using custom kernels, graphics-focused appliances, or DMA-BUF-heavy media workloads should check their vendor’s changelog for both the original udmabuf change and the later begin_cpu_udmabuf() synchronization fix before treating the issue as closed.
• Organizations that enable DMA API debugging should expect the original warning scenario to be most visible in their test and validation kernels, especially where AMDGPU and shared media buffers are involved.

The immediate operational conclusion is straightforward: do not deploy or validate against CVE-2026-64590 as though it were a documented Microsoft Windows patch. Track the Microsoft advisory for its missing product and remediation details, while treating the upstream Linux follow-up as an essential part of the technical record. The meaningful version boundary is not simply whether a kernel has the two-line

change, but whether it also carries the correction that restores synchronization on the first CPU access.

References​

1. Primary source: MSRC
   Published: August 9, 2026 at 8:43 AM UTC
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
2. Related coverage: msrc.microsoft.com
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: nvd.nist.gov
   
   

   Vulnerability APIs

   nvd.nist.gov
4. Related coverage: nvd.nist.gov
   
   https://nvd.nist.gov/vuln/data-feeds?source=post_page---------------------------
5. Related coverage: cve.org
   
   https://www.cve.org/ResourcesSupport/FAQs
6. Related coverage: nvlpubs.nist.gov
   
   

   Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.4

   The Security Content Automation Protocol (SCAP) is a suite of specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. This publication, along with its annex (NIST Special Publication...

   nvlpubs.nist.gov
7. Related coverage: cve.mitre.org
   
   CVE - CVE
8. Related coverage: cve.org
   
   

   Using Vulnogram with CVE Services

   PDF document

   www.cve.org