From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-64590: dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning
Date: Thu, 6 Aug 2026 09:13:53 +0200 [thread overview]
Message-ID: <2026080650-CVE-2026-64590-9eca@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning
When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM
driver (e.g. amdgpu for video playback in GNOME Videos / Showtime)
triggers a spurious warning:
DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \
overlapping mappings aren't supported
WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0
The call chain is:
amdgpu_cs_ioctl
-> amdgpu_ttm_backend_bind
-> dma_buf_map_attachment
-> [udmabuf] map_udmabuf -> get_sg_table
-> dma_map_sgtable(dev, sg, direction, 0) // attrs=0
-> debug_dma_map_sg -> add_dma_entry -> EEXIST
This happens because udmabuf builds a per-page scatter-gather list via
sg_set_folio(). When begin_cpu_udmabuf() has already created an sg
table mapped for the misc device, and an importer such as amdgpu maps
the same pages for its own device via map_udmabuf(), the DMA debug
infrastructure sees two active mappings whose physical addresses share
cacheline boundaries and warns about the overlap.
The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in
add_dma_entry() because it signals that no CPU cache maintenance is
performed at map/unmap time, making the cacheline overlap harmless.
All other major dma-buf exporters already pass this flag:
- drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC
- amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC
The CPU sync at map/unmap time is also redundant for udmabuf:
begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit
cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU
access is requested through the dma-buf interface.
Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and
dma_unmap_sgtable() in udmabuf to suppress the spurious warning and
skip the redundant sync.
The Linux kernel CVE team has assigned CVE-2026-64590 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.6 with commit 284562e1f34874e267d4f499362c3816f8f6bc3f and fixed in 6.6.148 with commit 0db56e7eae932f8e2f3eb44ad1a63633d8f504f8
Issue introduced in 5.6 with commit 284562e1f34874e267d4f499362c3816f8f6bc3f and fixed in 6.12.96 with commit d6552f5cff795d60e629f37513ecf23d88fd2f82
Issue introduced in 5.6 with commit 284562e1f34874e267d4f499362c3816f8f6bc3f and fixed in 6.18.39 with commit 34696563461c9a23177feb6d8aff43f4c0510278
Issue introduced in 5.6 with commit 284562e1f34874e267d4f499362c3816f8f6bc3f and fixed in 7.1.4 with commit 0449a6583c0ee76778d314e4e82f166fc97fa9d8
Issue introduced in 5.6 with commit 284562e1f34874e267d4f499362c3816f8f6bc3f and fixed in 7.2-rc1 with commit 504e2b4ab97a51d56d966cd36d0997ad30b65b2d
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-64590
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/dma-buf/udmabuf.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/0db56e7eae932f8e2f3eb44ad1a63633d8f504f8
https://git.kernel.org/stable/c/d6552f5cff795d60e629f37513ecf23d88fd2f82
https://git.kernel.org/stable/c/34696563461c9a23177feb6d8aff43f4c0510278
https://git.kernel.org/stable/c/0449a6583c0ee76778d314e4e82f166fc97fa9d8
https://git.kernel.org/stable/c/504e2b4ab97a51d56d966cd36d0997ad30b65b2d
reply other threads:[~2026-08-06 7:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026080650-CVE-2026-64590-9eca@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.