--- /dev/null
+From 504e2b4ab97a51d56d966cd36d0997ad30b65b2d Mon Sep 17 00:00:00 2001
+From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
+Date: Tue, 31 Mar 2026 11:16:57 +0500
+Subject: dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning
+
+From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
+
+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>
+---
+ drivers/dma-buf/udmabuf.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/dma-buf/udmabuf.c
++++ b/drivers/dma-buf/udmabuf.c
+@@ -127,7 +127,7 @@ static struct sg_table *get_sg_table(str
+ sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE,
+ ubuf->offsets[i]);
+
+- ret = dma_map_sgtable(dev, sg, direction, 0);
++ ret = dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC);
+ if (ret < 0)
+ goto err_map;
+ return sg;
+@@ -142,7 +142,7 @@ err_alloc:
+ static void put_sg_table(struct device *dev, struct sg_table *sg,
+ enum dma_data_direction direction)
+ {
+- dma_unmap_sgtable(dev, sg, direction, 0);
++ dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC);
+ sg_free_table(sg);
+ kfree(sg);
+ }
--- /dev/null
+From 69fe699afe1afcb730164b86c228483c2da05f94 Mon Sep 17 00:00:00 2001
+From: Weinan Liu <wnliu@google.com>
+Date: Thu, 28 May 2026 22:31:47 +0000
+Subject: iommu/amd: Don't split flush for amd_iommu_domain_flush_all()
+
+From: Weinan Liu <wnliu@google.com>
+
+commit 69fe699afe1afcb730164b86c228483c2da05f94 upstream.
+
+We have observed multiple full invalidations occurring during device
+detach when we are done using the vfio-device.
+
+blocked_domain_attach_device()
+ -> detach_device()
+ -> amd_iommu_domain_flush_all()
+ -> amd_iommu_domain_flush_pages(..., CMD_INV_IOMMU_ALL_PAGES_ADDRESS)
+
+ while (size != 0) {
+
+ -> __domain_flush_pages( flush_size /* power of 2 flush_size */)
+ -> domain_flush_pages_v1()
+ -> build_inv_iommu_pages()
+ -> build_inv_address()
+
+ }
+
+build_inv_address() will trigger a full invalidation if the chunk
+size > (1 << 51). Consequently, the guest will issue multiple full
+invalidations for a single call to amd_iommu_domain_flush_all()
+
+Without this patch, we will see 10 time instead of 1 time full
+invalidations for every amd_iommu_domain_flush_all().
+
+Cc: stable@vger.kernel.org
+Fixes: a270be1b3fdf ("iommu/amd: Use only natural aligned flushes in a VM")
+Suggested-by: Josef Bacik <josef@toxicpanda.com>
+Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Weinan Liu <wnliu@google.com>
+Reviewed-by: Wei Wang <wei.w.wang@hotmail.com>
+Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
+Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
+Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/amd/iommu.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/iommu/amd/iommu.c
++++ b/drivers/iommu/amd/iommu.c
+@@ -1702,7 +1702,8 @@ void amd_iommu_domain_flush_pages(struct
+ {
+ lockdep_assert_held(&domain->lock);
+
+- if (likely(!amd_iommu_np_cache)) {
++ if (likely(!amd_iommu_np_cache) ||
++ size >= (1ULL<<52)) {
+ __domain_flush_pages(domain, address, size);
+
+ /* Wait until IOMMU TLB and all device IOTLB flushes are complete */
--- /dev/null
+From 4d70986002f2f3eaaed89124fb2522bded38b016 Mon Sep 17 00:00:00 2001
+From: Nicolin Chen <nicolinc@nvidia.com>
+Date: Wed, 3 Jun 2026 14:26:53 -0700
+Subject: iommufd: Set upper bounds on cache invalidation entry_num and entry_len
+
+From: Nicolin Chen <nicolinc@nvidia.com>
+
+commit 4d70986002f2f3eaaed89124fb2522bded38b016 upstream.
+
+iommufd_hwpt_invalidate() takes a user-controlled entry_num and entry_len,
+each bounded only by U32_MAX. An entry_len beyond the kernel's struct size
+makes the copy helper verify the extra bytes are zero, scanning that excess
+in one uninterruptible pass; a multi-gigabyte value over zeroed user memory
+trips the soft-lockup watchdog.
+
+A large entry_num is the other half, driving the backend invalidation loop
+with no reschedule. The VT-d nested handler, for one, copies each entry and
+flushes caches per iteration, pinning the CPU on a non-preemptible kernel.
+
+Cap both in the ioctl. entry_len is held under PAGE_SIZE, above any request
+struct, and entry_num under 1 << 19, the order of a hardware invalidation
+queue and well beyond any real batch, bounding the per-call loop length.
+
+Fixes: 8c6eabae3807 ("iommufd: Add IOMMU_HWPT_INVALIDATE")
+Link: https://patch.msgid.link/r/447fa93663f7526eb361719e83fa8b649464483d.1780521606.git.nicolinc@nvidia.com
+Cc: stable@vger.kernel.org
+Assisted-by: Claude:claude-opus-4-8
+Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
+Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/iommufd/hw_pagetable.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/iommu/iommufd/hw_pagetable.c
++++ b/drivers/iommu/iommufd/hw_pagetable.c
+@@ -406,6 +406,9 @@ int iommufd_hwpt_get_dirty_bitmap(struct
+ return rc;
+ }
+
++/* An arbitrary entry_num cap, far above any realistic invalidation batch */
++#define IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX (1U << 19)
++
+ int iommufd_hwpt_invalidate(struct iommufd_ucmd *ucmd)
+ {
+ struct iommu_hwpt_invalidate *cmd = ucmd->cmd;
+@@ -424,7 +427,13 @@ int iommufd_hwpt_invalidate(struct iommu
+ goto out;
+ }
+
+- if (cmd->entry_num && (!cmd->data_uptr || !cmd->entry_len)) {
++ /*
++ * Bound entry_num and entry_len so a single call cannot pin the CPU;
++ * entry_len also caps the copy_struct_from_user() trailing-zero scan.
++ */
++ if (cmd->entry_num &&
++ (!cmd->data_uptr || !cmd->entry_len || cmd->entry_len > PAGE_SIZE ||
++ cmd->entry_num > IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX)) {
+ rc = -EINVAL;
+ goto out;
+ }
--- /dev/null
+From 7ef78d71ca713d8c00f7c34ddcf276c808143f77 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 18 Jun 2026 10:43:46 -0700
+Subject: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 7ef78d71ca713d8c00f7c34ddcf276c808143f77 upstream.
+
+When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in
+guest mode so that a future change can have update CR8 intercepts during
+vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion.
+
+ ------------[ cut here ]------------
+ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count))
+ WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879
+ WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879
+ Modules linked in:
+ CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
+ RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline]
+ RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879
+ Call Trace:
+ <TASK>
+ apic_update_ppr arch/x86/kvm/lapic.c:984 [inline]
+ kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023
+ kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986
+ kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847
+ kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201
+ kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159
+ vfs_ioctl fs/ioctl.c:51 [inline]
+ __do_sys_ioctl fs/ioctl.c:597 [inline]
+ __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
+ do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
+ do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+ </TASK>
+
+No functional change intended.
+
+Reported-by: syzbot ci <syzbot+ci493c6d734b63e050@syzkaller.appspotmail.com>
+Closes: https://lore.kernel.org/all/6a2adf3b.3b0a2d4e.8c8d1.0012.GAE@google.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-ID: <20260618174347.1981064-2-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/vmx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -6707,11 +6707,10 @@ static noinstr void vmx_l1d_flush(struct
+
+ void vmx_update_cr8_intercept(struct kvm_vcpu *vcpu, int tpr, int irr)
+ {
+- struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
+ int tpr_threshold;
+
+ if (is_guest_mode(vcpu) &&
+- nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW))
++ nested_cpu_has(get_vmcs12(vcpu), CPU_BASED_TPR_SHADOW))
+ return;
+
+ tpr_threshold = (irr == -1 || tpr < irr) ? 0 : irr;
--- /dev/null
+From c5bad4fa2d5dfd8c25140051a9807eba387a19b8 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Fri, 15 May 2026 15:26:29 -0700
+Subject: KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit c5bad4fa2d5dfd8c25140051a9807eba387a19b8 upstream.
+
+Move KVM's stuffing of GUEST_PENDING_DBG_EXCEPTIONS.BS when RFLAGS.TF=1 and
+MOV/POP SS or STI blocking is active into the exception injection code so
+that KVM fixes up the VMCS for all injected #DBs, not only those that are
+reflected back into the guest after #DB interception. E.g. if KVM queues
+a #DB in the emulator, or more importantly if userspace does save/restore
+exactly on the #DB+shadow boundary, then KVM needs to massage the VMCS to
+avoid the VM-Entry consistency check.
+
+Opportunistically update the wording of the comment to describe the
+behavior as a workaround of flawed CPU behavior/architecture, to make it
+clear that the *only* thing KVM is doing is fudging around a consistency
+check. Per the SDM:
+
+ There are no pending debug exceptions after VM entry if any of the
+ following are true:
+
+ * The VM entry is vectoring with one of the following interruption
+ types: external interrupt, non-maskable interrupt (NMI), hardware
+ exception, or privileged software exception.
+
+I.e. forcing GUEST_PENDING_DBG_EXCEPTIONS.BS does *not* impact guest-
+visible behavior.
+
+Fixes: b9bed78e2fa9 ("KVM: VMX: Set vmcs.PENDING_DBG.BS on #DB in STI/MOVSS blocking shadow")
+Cc: stable@vger.kernel.org
+Reported-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
+Closes: https://lore.kernel.org/all/b1a294bc9ed4dae532474a5dc6c8cb6e5962de7c.1757416809.git.houwenlong.hwl@antgroup.com
+Reviewed-by: Hou Wenlong <houwenlong.hwl@antgroup.com>
+Link: https://patch.msgid.link/20260515222638.1949982-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/vmx.c | 35 ++++++++++++++++++-----------------
+ 1 file changed, 18 insertions(+), 17 deletions(-)
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -1833,6 +1833,24 @@ void vmx_inject_exception(struct kvm_vcp
+ u32 intr_info = ex->vector | INTR_INFO_VALID_MASK;
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
+
++ /*
++ * When injecting a #DB, single-stepping is enabled in RFLAGS, and STI
++ * or MOV-SS blocking is active, set vmcs.PENDING_DBG_EXCEPTIONS.BS to
++ * prevent a false positive from VM-Entry consistency check. VM-Entry
++ * asserts that a single-step #DB _must_ be pending in this scenario,
++ * as the previous instruction cannot have toggled RFLAGS.TF 0=>1
++ * (because STI and POP/MOV don't modify RFLAGS), therefore the one
++ * instruction delay when activating single-step breakpoints must have
++ * already expired. However, the CPU isn't smart enough to peek at
++ * vmcs.VM_ENTRY_INTR_INFO_FIELD and so doesn't realize that yes, there
++ * is indeed a #DB pending/imminent.
++ */
++ if (ex->vector == DB_VECTOR &&
++ (vmx_get_rflags(vcpu) & X86_EFLAGS_TF) &&
++ vmx_get_interrupt_shadow(vcpu))
++ vmcs_writel(GUEST_PENDING_DBG_EXCEPTIONS,
++ vmcs_readl(GUEST_PENDING_DBG_EXCEPTIONS) | DR6_BS);
++
+ kvm_deliver_exception_payload(vcpu, ex);
+
+ if (ex->has_error_code) {
+@@ -5323,26 +5341,9 @@ static int handle_exception_nmi(struct k
+ * avoid single-step #DB and MTF updates, as ICEBP is
+ * higher priority. Note, skipping ICEBP still clears
+ * STI and MOVSS blocking.
+- *
+- * For all other #DBs, set vmcs.PENDING_DBG_EXCEPTIONS.BS
+- * if single-step is enabled in RFLAGS and STI or MOVSS
+- * blocking is active, as the CPU doesn't set the bit
+- * on VM-Exit due to #DB interception. VM-Entry has a
+- * consistency check that a single-step #DB is pending
+- * in this scenario as the previous instruction cannot
+- * have toggled RFLAGS.TF 0=>1 (because STI and POP/MOV
+- * don't modify RFLAGS), therefore the one instruction
+- * delay when activating single-step breakpoints must
+- * have already expired. Note, the CPU sets/clears BS
+- * as appropriate for all other VM-Exits types.
+ */
+ if (is_icebp(intr_info))
+ WARN_ON(!skip_emulated_instruction(vcpu));
+- else if ((vmx_get_rflags(vcpu) & X86_EFLAGS_TF) &&
+- (vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) &
+- (GUEST_INTR_STATE_STI | GUEST_INTR_STATE_MOV_SS)))
+- vmcs_writel(GUEST_PENDING_DBG_EXCEPTIONS,
+- vmcs_readl(GUEST_PENDING_DBG_EXCEPTIONS) | DR6_BS);
+
+ kvm_queue_exception_p(vcpu, DB_VECTOR, dr6);
+ return 1;
--- /dev/null
+From 0ffedf43910e44b76c2c1db4e9fbf12b268190c1 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 23 Apr 2026 09:26:27 -0700
+Subject: KVM: x86: Ensure vendor's exit handler runs before fastpath userspace exits
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 0ffedf43910e44b76c2c1db4e9fbf12b268190c1 upstream.
+
+Move the handling of fastpath userspace exits into vendor code to ensure
+KVM runs vendor specific operations that need to run before userspace gains
+control of the vCPU. E.g. for VMX (and soon to be for SVM as well), KVM
+needs to flush the PML buffer prior to exiting to userspace, otherwise any
+memory written by the final KVM_RUN might never be flagged as dirty.
+
+Note, waiting to snapshot CR0 and CR3 until svm_handle_exit() is flawed in
+general, as that risks consuming stale state in a fastpath handler. That
+will be addressed in a future change.
+
+Fixes: f7f39c50edb9 ("KVM: x86: Exit to userspace if fastpath triggers one on instruction skip")
+Cc: stable@vger.kernel.org
+Cc: Nikunj A. Dadhania <nikunj@amd.com>
+Reviewed-by: Nikunj A. Dadhania <nikunj@amd.com>
+Reviewed-by: Kai Huang <kai.huang@intel.com>
+Link: https://patch.msgid.link/20260423162628.490962-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 3 +++
+ arch/x86/kvm/vmx/vmx.c | 3 +++
+ arch/x86/kvm/x86.c | 3 ---
+ 3 files changed, 6 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -3662,6 +3662,9 @@ static int svm_handle_exit(struct kvm_vc
+ vcpu->arch.cr3 = svm->vmcb->save.cr3;
+ }
+
++ if (unlikely(exit_fastpath == EXIT_FASTPATH_EXIT_USERSPACE))
++ return 0;
++
+ if (is_guest_mode(vcpu)) {
+ int vmexit;
+
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -6452,6 +6452,9 @@ static int __vmx_handle_exit(struct kvm_
+ if (enable_pml && !is_guest_mode(vcpu))
+ vmx_flush_pml_buffer(vcpu);
+
++ if (unlikely(exit_fastpath == EXIT_FASTPATH_EXIT_USERSPACE))
++ return 0;
++
+ /*
+ * KVM should never reach this point with a pending nested VM-Enter.
+ * More specifically, short-circuiting VM-Entry to emulate L2 due to
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -11199,9 +11199,6 @@ static int vcpu_enter_guest(struct kvm_v
+ if (vcpu->arch.apic_attention)
+ kvm_lapic_sync_from_vapic(vcpu);
+
+- if (unlikely(exit_fastpath == EXIT_FASTPATH_EXIT_USERSPACE))
+- return 0;
+-
+ r = kvm_x86_call(handle_exit)(vcpu, exit_fastpath);
+ return r;
+
selftests-mm-fix-and-speedup-droppable-test.patch
mm-do-file-ownership-checks-with-the-proper-mount-idmap.patch
selftests-mm-pagemap_ioctl-use-the-correct-page-size-for-transact_test.patch
+iommu-amd-don-t-split-flush-for-amd_iommu_domain_flush_all.patch
+iommufd-set-upper-bounds-on-cache-invalidation-entry_num-and-entry_len.patch
+kvm-vmx-refresh-guest_pending_dbg_exceptions.bs-on-all-injected-dbs.patch
+kvm-x86-ensure-vendor-s-exit-handler-runs-before-fastpath-userspace-exits.patch
+kvm-vmx-grab-vmcs12-on-cr8-interception-update-iff-vcpu-is-in-guest-mode.patch
+udmabuf-fix-dma-direction-mismatch-in-release_udmabuf.patch
+dma-buf-udmabuf-skip-redundant-cpu-sync-to-fix-cacheline-eexist-warning.patch
--- /dev/null
+From fb7b1a0ab25a6077d26cb3829e31743972d4f31d Mon Sep 17 00:00:00 2001
+From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
+Date: Sun, 15 Mar 2026 04:27:22 +0500
+Subject: udmabuf: fix DMA direction mismatch in release_udmabuf()
+
+From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
+
+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>
+---
+ drivers/dma-buf/udmabuf.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/dma-buf/udmabuf.c
++++ b/drivers/dma-buf/udmabuf.c
+@@ -28,6 +28,7 @@ struct udmabuf {
+ pgoff_t pagecount;
+ struct folio **folios;
+ struct sg_table *sg;
++ enum dma_data_direction sg_dir;
+ struct miscdevice *device;
+ pgoff_t *offsets;
+ struct list_head unpin_list;
+@@ -193,7 +194,7 @@ static void release_udmabuf(struct dma_b
+ struct device *dev = ubuf->device->this_device;
+
+ if (ubuf->sg)
+- put_sg_table(dev, ubuf->sg, DMA_BIDIRECTIONAL);
++ put_sg_table(dev, ubuf->sg, ubuf->sg_dir);
+
+ unpin_all_folios(&ubuf->unpin_list);
+ kvfree(ubuf->offsets);
+@@ -213,6 +214,8 @@ static int begin_cpu_udmabuf(struct dma_
+ if (IS_ERR(ubuf->sg)) {
+ ret = PTR_ERR(ubuf->sg);
+ ubuf->sg = NULL;
++ } else {
++ ubuf->sg_dir = direction;
+ }
+ } else {
+ dma_sync_sgtable_for_cpu(dev, ubuf->sg, direction);
projects / thirdparty / kernel / stable-queue.git / commitdiff
