linux-stable.git/drivers/dma-buf, branch linux-rolling-stable Linux kernel stable tree dma-buf: dma-fence: Fix potential NULL pointer dereference 2026-07-24T14:21:11+00:00 Philipp Stanner phasta@kernel.org 2026-06-29T07:56:37+00:00 15ecfdf0ef6f6d874d0a26690d300857b39ebfd0 commit 035219a760edb35ae9a9e96beba7f122e26a997b upstream. The commit mentioned in the fixes tag below introduced a mechanism through which fence producers can fully decouple from fence consumers. This, desirable, mechanism is based on the fence's signaled-bit as the "decoupling point". A sophisticated interaction between RCU and atomic instructions attempts to ensure that fence consumers can still interact with fence producers through the dma_fence_ops (callback pointers into the producer). This is the desired behavior: to check for decoupling, the signaled-bit is first checked. If it's not yet signaled, RCU ensures that the ops pointer cannot yet be NULL. Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit, and then sets the ops pointer to NULL. Readers first load the ops pointer, and then check through the signaled-bit whether the pointer can legally be accessed. These set and load operations could occur out of order on weakly ordered platforms. This problem can be solved very elegantly by using the ops pointer itself as the synchronization point. The pointer is either NULL, or cannot become NULL while it is being used thanks to RCU. Replace the signaled-bit check in dma_fence_timeline_name() and dma_fence_driver_name(). Cc: stable@vger.kernel.org Fixes: f4cc3ab824d6 ("dma-buf: protected fence ops by RCU v8") Signed-off-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20260629075636.2513214-2-phasta@kernel.org Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 035219a760edb35ae9a9e96beba7f122e26a997b upstream.

The commit mentioned in the fixes tag below introduced a mechanism
through which fence producers can fully decouple from fence consumers.
This, desirable, mechanism is based on the fence's signaled-bit as the
"decoupling point".

A sophisticated interaction between RCU and atomic instructions attempts
to ensure that fence consumers can still interact with fence producers
through the dma_fence_ops (callback pointers into the producer).

This is the desired behavior: to check for decoupling, the signaled-bit
is first checked. If it's not yet signaled, RCU ensures that the ops
pointer cannot yet be NULL.

Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit,
and then sets the ops pointer to NULL. Readers first load the ops
pointer, and then check through the signaled-bit whether the pointer can
legally be accessed.

These set and load operations could occur out of order on weakly ordered
platforms. This problem can be solved very elegantly by using the ops
pointer itself as the synchronization point. The pointer is either NULL,
or cannot become NULL while it is being used thanks to RCU.

Replace the signaled-bit check in dma_fence_timeline_name() and
dma_fence_driver_name().

Cc: stable@vger.kernel.org
Fixes: f4cc3ab824d6 ("dma-buf: protected fence ops by RCU v8")
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20260629075636.2513214-2-phasta@kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dma-fence: use correct callback in dma_fence_timeline_name() 2026-07-24T14:21:11+00:00 André Draszik andre.draszik@linaro.org 2026-06-18T12:00:39+00:00 562d5e6f9b994058e3b72536f5a1fd461a30bc16 commit 032a6f6ce21fc701468fd15403d2f53a30107f5b upstream. dma_fence_timeline_name() is a wrapper around dma_fence_ops::get_timeline_name(). Since the blamed commit below, it calls an incorrect callback. Update it to restore functionality by calling the intended callback. Fixes: 62918542b7bf ("dma-fence: Fix sparse warnings due __rcu annotations") Cc: <stable@vger.kernel.org> # v7.1+ [tursulin: added cc stable] Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: Philipp Stanner <phasta@kernel.org> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix-v1-1-801f29c9853d@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 032a6f6ce21fc701468fd15403d2f53a30107f5b upstream.

dma_fence_timeline_name() is a wrapper around
dma_fence_ops::get_timeline_name(). Since the blamed commit below, it
calls an incorrect callback.

Update it to restore functionality by calling the intended callback.

Fixes: 62918542b7bf ("dma-fence: Fix sparse warnings due __rcu annotations")
Cc: <stable@vger.kernel.org> # v7.1+
[tursulin: added cc stable]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix-v1-1-801f29c9853d@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dma-fence: Make dma_fence_dedup_array() robust against 0-count input 2026-07-24T14:21:11+00:00 Baineng Shou shoubaineng@gmail.com 2026-06-29T03:13:46+00:00 e2d9a2ea178a5da0b4a6693e8ebca5c7fc4d7051 commit 77a9298741f8f9e8b963c977f5582ab21c6d3427 upstream. dma_fence_dedup_array() returns 1 when called with num_fences == 0: the for-loop body never executes, j stays at 0, and the final `return ++j` yields 1. This contradicts both the kernel-doc ("Return: Number of unique fences remaining in the array") and the natural expectation that 0 input gives 0 output. The caller __dma_fence_unwrap_merge() bails out via the `if (count == 0 || count == 1)` fast path and so is save. But amdgpu_userq_wait_*() could reach the dedup call with a zero local count and dereference an uninitialized fence slot in the array. Make the contract match the documentation by returning 0 early. This also skips an unnecessary sort() call on an empty array. Cc: stable@vger.kernel.org Signed-off-by: Baineng Shou <shoubaineng@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Fixes: 575ec9b0c2f1 ("dma-fence: Add helper to sort and deduplicate dma_fence arrays") Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260629031346.3875683-1-shoubaineng@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 77a9298741f8f9e8b963c977f5582ab21c6d3427 upstream.

dma_fence_dedup_array() returns 1 when called with num_fences == 0:
the for-loop body never executes, j stays at 0, and the final
`return ++j` yields 1. This contradicts both the kernel-doc ("Return:
Number of unique fences remaining in the array") and the natural
expectation that 0 input gives 0 output.

The caller __dma_fence_unwrap_merge() bails out via the
`if (count == 0 || count == 1)` fast path and so is save.

But amdgpu_userq_wait_*() could reach the dedup call with a zero local
count and dereference an uninitialized fence slot in the array.

Make the contract match the documentation by returning 0 early. This
also skips an unnecessary sort() call on an empty array.

Cc: stable@vger.kernel.org
Signed-off-by: Baineng Shou <shoubaineng@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Fixes: 575ec9b0c2f1 ("dma-fence: Add helper to sort and deduplicate dma_fence arrays")
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260629031346.3875683-1-shoubaineng@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dma-fence: Fix potential tracepoint null pointer dereferences 2026-07-24T14:19:02+00:00 Tvrtko Ursulin tvrtko.ursulin@igalia.com 2026-04-15T08:32:07+00:00 4e01fc9a5bc49b04fad403ffa71299b35e132ca8 [ Upstream commit e94b9f01543cc6a83538c2c2cc645a424d3015ca ] Trace_dma_fence_signaled, trace_dma_fence_wait_end and trace_dma_fence_destroy can all currently dereference a null fence->ops pointer after it has been reset on fence signalling. Lets use the safe string getters for most tracepoints to avoid this class of a problem, while for the signal tracepoint we move it to before ops are cleared to avoid losing the driver and timeline name information. Apart from moving it we also need to add a new tracepoint class to bypass the safe name getters since the signaled bit is already set. For dma_fence_init we also need to use the new tracepoint class since the rcu read lock is not held there, and we can do the same for the enable signaling since there we are certain the fence cannot be signaled while we are holding the lock and have even validated the fence->ops. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Cc: Christian König <christian.koenig@amd.com> Cc: Philipp Stanner <phasta@kernel.org> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260415083207.40513-2-tvrtko.ursulin@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e94b9f01543cc6a83538c2c2cc645a424d3015ca ]

Trace_dma_fence_signaled, trace_dma_fence_wait_end and
trace_dma_fence_destroy can all currently dereference a null fence->ops
pointer after it has been reset on fence signalling.

Lets use the safe string getters for most tracepoints to avoid this class
of a problem, while for the signal tracepoint we move it to before ops are
cleared to avoid losing the driver and timeline name information. Apart
from moving it we also need to add a new tracepoint class to bypass the
safe name getters since the signaled bit is already set.

For dma_fence_init we also need to use the new tracepoint class since the
rcu read lock is not held there, and we can do the same for the enable
signaling since there we are certain the fence cannot be signaled while
we are holding the lock and have even validated the fence->ops.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
Cc: Christian König <christian.koenig@amd.com>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260415083207.40513-2-tvrtko.ursulin@igalia.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning 2026-07-18T14:55:47+00:00 Mikhail Gavrilov mikhail.v.gavrilov@gmail.com 2026-03-31T06:16:57+00:00 0449a6583c0ee76778d314e4e82f166fc97fa9d8 commit 504e2b4ab97a51d56d966cd36d0997ad30b65b2d upstream. 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. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patch.msgid.link/20260331061657.79983-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 504e2b4ab97a51d56d966cd36d0997ad30b65b2d upstream.

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.

Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks")
Cc: stable@vger.kernel.org
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Link: https://patch.msgid.link/20260331061657.79983-1-mikhail.v.gavrilov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
udmabuf: fix DMA direction mismatch in release_udmabuf() 2026-07-18T14:55:47+00:00 Mikhail Gavrilov mikhail.v.gavrilov@gmail.com 2026-03-14T23:27:22+00:00 18bd476ef4a1094d27c7084069f4c1e177e309d8 commit fb7b1a0ab25a6077d26cb3829e31743972d4f31d upstream. begin_cpu_udmabuf() maps the sg_table with the caller-provided direction (e.g., DMA_TO_DEVICE for a write-only sync), and caches it in ubuf->sg for reuse. However, release_udmabuf() always unmaps this sg_table with a hardcoded DMA_BIDIRECTIONAL, regardless of the direction that was originally used for the mapping. With CONFIG_DMA_API_DEBUG=y this produces: DMA-API: misc udmabuf: device driver frees DMA memory with different direction [device address=0x000000044a123000] [size=4096 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] The issue was found during video playback when GStreamer performed a write-only DMA_BUF_IOCTL_SYNC on a udmabuf. It can be reproduced with CONFIG_DMA_API_DEBUG=y by creating a udmabuf from a memfd, performing a write-only sync (DMA_BUF_SYNC_WRITE without DMA_BUF_SYNC_READ), and closing the file descriptor. Fix this by storing the DMA direction used when the sg_table is first created in begin_cpu_udmabuf(), and passing that same direction to put_sg_table() in release_udmabuf(). Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Reviewed-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patch.msgid.link/20260314232722.15555-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fb7b1a0ab25a6077d26cb3829e31743972d4f31d upstream.

begin_cpu_udmabuf() maps the sg_table with the caller-provided direction
(e.g., DMA_TO_DEVICE for a write-only sync), and caches it in ubuf->sg
for reuse.  However, release_udmabuf() always unmaps this sg_table with
a hardcoded DMA_BIDIRECTIONAL, regardless of the direction that was
originally used for the mapping.

With CONFIG_DMA_API_DEBUG=y this produces:

  DMA-API: misc udmabuf: device driver frees DMA memory with different
  direction [device address=0x000000044a123000] [size=4096 bytes]
  [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL]

The issue was found during video playback when GStreamer performed a
write-only DMA_BUF_IOCTL_SYNC on a udmabuf.  It can be reproduced
with CONFIG_DMA_API_DEBUG=y by creating a udmabuf from a memfd,
performing a write-only sync (DMA_BUF_SYNC_WRITE without
DMA_BUF_SYNC_READ), and closing the file descriptor.

Fix this by storing the DMA direction used when the sg_table is first
created in begin_cpu_udmabuf(), and passing that same direction to
put_sg_table() in release_udmabuf().

Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks")
Cc: stable@vger.kernel.org
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Reviewed-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Link: https://patch.msgid.link/20260314232722.15555-1-mikhail.v.gavrilov@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dma-buf: fix UAF in dma_buf_fd() tracepoint 2026-05-28T14:35:43+00:00 David Carlier devnexen@gmail.com 2026-05-23T18:14:46+00:00 ead6680f354f83966c796fc7f9463a3171789616 Once FD_ADD() returns, the fd is live in the file descriptor table and a thread sharing that table can close() it before DMA_BUF_TRACE() runs. The close drops the last reference, __fput() frees the dma_buf, and the tracepoint then dereferences dmabuf to take dmabuf->name_lock -- slab-use-after-free. Split FD_ADD() back into get_unused_fd_flags() + fd_install() and emit the tracepoint between them. While the fdtable slot is reserved with a NULL file pointer, a racing close() returns -EBADF without entering __fput(), so the dma_buf stays alive across the trace. Same approach as commit 2d76319c4cbb ("dma-buf: fix UAF in dma_buf_put() tracepoint"). This undoes the FD_ADD() conversion done in commit 34dfce523c90 ("dma: convert dma_buf_fd() to FD_ADD()"); FD_ADD() has no place to hook the tracepoint safely. Reported-by: syzbot+7f4987d0afb97dd090cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f4987d0afb97dd090cb Fixes: 281a22631423 ("dma-buf: add some tracepoints to debug.") Cc: stable@vger.kernel.org # 7.0.x Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260523181446.69525-1-devnexen@gmail.com 
Once FD_ADD() returns, the fd is live in the file descriptor table
and a thread sharing that table can close() it before DMA_BUF_TRACE()
runs. The close drops the last reference, __fput() frees the dma_buf,
and the tracepoint then dereferences dmabuf to take dmabuf->name_lock
-- slab-use-after-free.

Split FD_ADD() back into get_unused_fd_flags() + fd_install() and
emit the tracepoint between them. While the fdtable slot is reserved
with a NULL file pointer, a racing close() returns -EBADF without
entering __fput(), so the dma_buf stays alive across the trace. Same
approach as commit 2d76319c4cbb ("dma-buf: fix UAF in dma_buf_put()
tracepoint").

This undoes the FD_ADD() conversion done in commit 34dfce523c90
("dma: convert dma_buf_fd() to FD_ADD()"); FD_ADD() has no place to
hook the tracepoint safely.

Reported-by: syzbot+7f4987d0afb97dd090cb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7f4987d0afb97dd090cb
Fixes: 281a22631423 ("dma-buf: add some tracepoints to debug.")
Cc: stable@vger.kernel.org # 7.0.x
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://patch.msgid.link/20260523181446.69525-1-devnexen@gmail.com
Merge tag 'drm-fixes-2026-04-24' of https://gitlab.freedesktop.org/drm/kernel 2026-04-24T18:44:52+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-04-24T18:44:52+00:00 cf950766e96e36c90871d955cfd2a2c1feddba37 Pull more drm fixes from Dave Airlie: "These are the regular fixes that have built up over last couple of weeks, all pretty minor and spread all over. atomic: - raise the vblank timeout to avoid it on virtual drivers - fix colorop duplication bridge: - stm_lvds: state check fix - dw-mipi-dsi: bridge reference leak fix panel: - visionx-rm69299: init fix dma-fence: - fix sparse warning dma-buf: - UAF fix panthor: - mapping fix arcgpu: - device_node reference leak fix nouveau: - memory leak in error path fix - overflow in reloc path for old hw fix hv: - Kconfig fix v3d: - infinite loop fix" * tag 'drm-fixes-2026-04-24' of https://gitlab.freedesktop.org/drm/kernel: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check MAINTAINERS: split hisilicon maintenance and add Yongbang Shi for hibmc-drm matainers drm/v3d: Reject empty multisync extension to prevent infinite loop drm/panel: visionox-rm69299: Make use of prepare_prev_first drm/drm_atomic: duplicate colorop states if plane color pipeline in use drm/nouveau: fix nvkm_device leak on aperture removal failure hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS dma-fence: Silence sparse warning in dma_fence_describe drm/bridge: dw-mipi-dsi: Fix bridge leak when host attach fails drm/arcpgu: fix device node leak drm/panthor: Fix outdated function documentation drm/panthor: Extend VM locked region for remap case to be a superset dma-buf: fix UAF in dma_buf_put() tracepoint drm/bridge: stm_lvds: Do not fail atomic_check on disabled connector drm/atomic: Increase timeout in drm_atomic_helper_wait_for_vblanks() 
Pull more drm fixes from Dave Airlie:
 "These are the regular fixes that have built up over last couple of
  weeks, all pretty minor and spread all over.

  atomic:
   - raise the vblank timeout to avoid it on virtual drivers
   - fix colorop duplication

  bridge:
   - stm_lvds: state check fix
   - dw-mipi-dsi: bridge reference leak fix

  panel:
   - visionx-rm69299: init fix

  dma-fence:
   - fix sparse warning

  dma-buf:
   - UAF fix

  panthor:
   - mapping fix

  arcgpu:
   - device_node reference leak fix

  nouveau:
   - memory leak in error path fix
   - overflow in reloc path for old hw fix

  hv:
   - Kconfig fix

  v3d:
   - infinite loop fix"

* tag 'drm-fixes-2026-04-24' of https://gitlab.freedesktop.org/drm/kernel:
  drm/nouveau: fix u32 overflow in pushbuf reloc bounds check
  MAINTAINERS: split hisilicon maintenance and add Yongbang Shi for hibmc-drm matainers
  drm/v3d: Reject empty multisync extension to prevent infinite loop
  drm/panel: visionox-rm69299: Make use of prepare_prev_first
  drm/drm_atomic: duplicate colorop states if plane color pipeline in use
  drm/nouveau: fix nvkm_device leak on aperture removal failure
  hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
  dma-fence: Silence sparse warning in dma_fence_describe
  drm/bridge: dw-mipi-dsi: Fix bridge leak when host attach fails
  drm/arcpgu: fix device node leak
  drm/panthor: Fix outdated function documentation
  drm/panthor: Extend VM locked region for remap case to be a superset
  dma-buf: fix UAF in dma_buf_put() tracepoint
  drm/bridge: stm_lvds: Do not fail atomic_check on disabled connector
  drm/atomic: Increase timeout in drm_atomic_helper_wait_for_vblanks()
Merge tag 'drm-next-2026-04-22' of https://gitlab.freedesktop.org/drm/kernel 2026-04-22T00:39:21+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-04-22T00:39:21+00:00 6596a02b207886e9e00bb0161c7fd59fea53c081 Pull more drm updates from Dave Airlie: "This is a followup which is mostly next material with some fixes. Alex pointed out I missed one of his AMD MRs from last week, so I added that, then Jani sent the pipe reordering stuff, otherwise it's just some minor i915 fixes and a dma-buf fix. drm: - Add support for AMD VSDB parsing to drm_edid dma-buf: - fix documentation formatting i915: - add support for reordered pipes to support joined pipes better - Fix VESA backlight possible check condition - Verify the correct plane DDB entry amdgpu: - Audio regression fix - Use drm edid parser for AMD VSDB - Misc cleanups - VCE cs parse fixes - VCN cs parse fixes - RAS fixes - Clean up and unify vram reservation handling - GPU Partition updates - system_wq cleanups - Add CONFIG_GCOV_PROFILE_AMDGPU kconfig option - SMU vram copy updates - SMU 13/14/15 fixes - UserQ fixes - Replace pasid idr with an xarray - Dither handling fix - Enable amdgpu by default for CIK APUs - Add IBs to devcoredump amdkfd: - system_wq cleanups radeon: - system_wq cleanups" * tag 'drm-next-2026-04-22' of https://gitlab.freedesktop.org/drm/kernel: (62 commits) drm/i915/display: change pipe allocation order for discrete platforms drm/i915/wm: Verify the correct plane DDB entry drm/i915/backlight: Fix VESA backlight possible check condition drm/i915: Walk crtcs in pipe order drm/i915/joiner: Make joiner "nomodeset" state copy independent of pipe order dma-buf: fix htmldocs error for dma_buf_attach_revocable drm/amdgpu: dump job ibs in the devcoredump drm/amdgpu: store ib info for devcoredump drm/amdgpu: extract amdgpu_vm_lock_by_pasid from amdgpu_vm_handle_fault drm/amdgpu: Use amdgpu by default for CIK APUs too drm/amd/display: Remove unused NUM_ELEMENTS macros drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZE drm/amdgpu: save ring content before resetting the device drm/amdgpu: make userq fence_drv drop explicit in queue destroy drm/amdgpu: rework userq fence driver alloc/destroy drm/amdgpu/userq: use dma_fence_wait_timeout without test for signalled drm/amdgpu/userq: call dma_resv_wait_timeout without test for signalled drm/amdgpu/userq: add the return code too in error condition drm/amdgpu/userq: fence wait for max time in amdgpu_userq_wait_for_signal drm/amd/display: Change dither policy for 10 bpc output back to dithering ... 
Pull more drm updates from Dave Airlie:
 "This is a followup which is mostly next material with some fixes.

  Alex pointed out I missed one of his AMD MRs from last week, so I
  added that, then Jani sent the pipe reordering stuff, otherwise it's
  just some minor i915 fixes and a dma-buf fix.

  drm:
   - Add support for AMD VSDB parsing to drm_edid

  dma-buf:
   - fix documentation formatting

  i915:
   - add support for reordered pipes to support joined pipes better
   - Fix VESA backlight possible check condition
   - Verify the correct plane DDB entry

  amdgpu:
   - Audio regression fix
   - Use drm edid parser for AMD VSDB
   - Misc cleanups
   - VCE cs parse fixes
   - VCN cs parse fixes
   - RAS fixes
   - Clean up and unify vram reservation handling
   - GPU Partition updates
   - system_wq cleanups
   - Add CONFIG_GCOV_PROFILE_AMDGPU kconfig option
   - SMU vram copy updates
   - SMU 13/14/15 fixes
   - UserQ fixes
   - Replace pasid idr with an xarray
   - Dither handling fix
   - Enable amdgpu by default for CIK APUs
   - Add IBs to devcoredump

  amdkfd:
   - system_wq cleanups

  radeon:
   - system_wq cleanups"

* tag 'drm-next-2026-04-22' of https://gitlab.freedesktop.org/drm/kernel: (62 commits)
  drm/i915/display: change pipe allocation order for discrete platforms
  drm/i915/wm: Verify the correct plane DDB entry
  drm/i915/backlight: Fix VESA backlight possible check condition
  drm/i915: Walk crtcs in pipe order
  drm/i915/joiner: Make joiner "nomodeset" state copy independent of pipe order
  dma-buf: fix htmldocs error for dma_buf_attach_revocable
  drm/amdgpu: dump job ibs in the devcoredump
  drm/amdgpu: store ib info for devcoredump
  drm/amdgpu: extract amdgpu_vm_lock_by_pasid from amdgpu_vm_handle_fault
  drm/amdgpu: Use amdgpu by default for CIK APUs too
  drm/amd/display: Remove unused NUM_ELEMENTS macros
  drm/amd/display: Replace inline NUM_ELEMENTS macro with ARRAY_SIZE
  drm/amdgpu: save ring content before resetting the device
  drm/amdgpu: make userq fence_drv drop explicit in queue destroy
  drm/amdgpu: rework userq fence driver alloc/destroy
  drm/amdgpu/userq: use dma_fence_wait_timeout without test for signalled
  drm/amdgpu/userq: call dma_resv_wait_timeout without test for signalled
  drm/amdgpu/userq: add the return code too in error condition
  drm/amdgpu/userq: fence wait for max time in amdgpu_userq_wait_for_signal
  drm/amd/display: Change dither policy for 10 bpc output back to dithering
  ...
Merge tag 'dma-mapping-7.1-2026-04-16' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux 2026-04-17T18:12:42+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-04-17T18:12:42+00:00 87768582a440e7049a04e8af7383b86738d15b38 Pull dma-mapping updates from Marek Szyprowski: - added support for batched cache sync, what improves performance of dma_map/unmap_sg() operations on ARM64 architecture (Barry Song) - introduced DMA_ATTR_CC_SHARED attribute for explicitly shared memory used in confidential computing (Jiri Pirko) - refactored spaghetti-like code in drivers/of/of_reserved_mem.c and its clients (Marek Szyprowski, shared branch with device-tree updates to avoid merge conflicts) - prepared Contiguous Memory Allocator related code for making dma-buf drivers modularized (Maxime Ripard) - added support for benchmarking dma_map_sg() calls to tools/dma utility (Qinxin Xia) * tag 'dma-mapping-7.1-2026-04-16' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: (24 commits) dma-buf: heaps: system: document system_cc_shared heap dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory mm: cma: Export cma_alloc(), cma_release() and cma_get_name() dma: contiguous: Export dev_get_cma_area() dma: contiguous: Make dma_contiguous_default_area static dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Turn heap registration logic around of: reserved_mem: rework fdt_init_reserved_mem_node() of: reserved_mem: clarify fdt_scan_reserved_mem*() functions of: reserved_mem: rearrange code a bit of: reserved_mem: replace CMA quirks by generic methods of: reserved_mem: switch to ops based OF_DECLARE() of: reserved_mem: use -ENODEV instead of -ENOENT of: reserved_mem: remove fdt node from the structure dma-mapping: fix false kernel-doc comment marker dma-mapping: Support batch mode for dma_direct_{map,unmap}_sg dma-mapping: Separate DMA sync issuing and completion waiting arm64: Provide dcache_inval_poc_nosync helper arm64: Provide dcache_clean_poc_nosync helper ... 
Pull dma-mapping updates from Marek Szyprowski:

 - added support for batched cache sync, what improves performance of
   dma_map/unmap_sg() operations on ARM64 architecture (Barry Song)

 - introduced DMA_ATTR_CC_SHARED attribute for explicitly shared memory
   used in confidential computing (Jiri Pirko)

 - refactored spaghetti-like code in drivers/of/of_reserved_mem.c and
   its clients (Marek Szyprowski, shared branch with device-tree updates
   to avoid merge conflicts)

 - prepared Contiguous Memory Allocator related code for making dma-buf
   drivers modularized (Maxime Ripard)

 - added support for benchmarking dma_map_sg() calls to tools/dma
   utility (Qinxin Xia)

* tag 'dma-mapping-7.1-2026-04-16' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: (24 commits)
  dma-buf: heaps: system: document system_cc_shared heap
  dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory
  dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory
  mm: cma: Export cma_alloc(), cma_release() and cma_get_name()
  dma: contiguous: Export dev_get_cma_area()
  dma: contiguous: Make dma_contiguous_default_area static
  dma: contiguous: Make dev_get_cma_area() a proper function
  dma: contiguous: Turn heap registration logic around
  of: reserved_mem: rework fdt_init_reserved_mem_node()
  of: reserved_mem: clarify fdt_scan_reserved_mem*() functions
  of: reserved_mem: rearrange code a bit
  of: reserved_mem: replace CMA quirks by generic methods
  of: reserved_mem: switch to ops based OF_DECLARE()
  of: reserved_mem: use -ENODEV instead of -ENOENT
  of: reserved_mem: remove fdt node from the structure
  dma-mapping: fix false kernel-doc comment marker
  dma-mapping: Support batch mode for dma_direct_{map,unmap}_sg
  dma-mapping: Separate DMA sync issuing and completion waiting
  arm64: Provide dcache_inval_poc_nosync helper
  arm64: Provide dcache_clean_poc_nosync helper
  ...