--- /dev/null
+From stable+bounces-203358-greg=kroah.com@vger.kernel.org Wed Dec 24 09:57:13 2025
+From: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Date: Wed, 24 Dec 2025 00:36:52 -0800
+Subject: drm/vmwgfx: Fix a null-ptr access in the cursor snooper
+To: stable@vger.kernel.org, gregkh@linuxfoundation.org
+Cc: zack.rusin@broadcom.com, bcm-kernel-feedback-list@broadcom.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, simona@ffwll.ch, airlied@gmail.com, brianp@vmware.com, dtor@vmware.com, airlied@redhat.com, thellstrom@vmware.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, ajay.kaher@broadcom.com, alexey.makhalov@broadcom.com, vamsi-krishna.brahmajosyula@broadcom.com, yin.ding@broadcom.com, tapas.kundu@broadcom.com, Kuzey Arda Bulut <kuzeyardabulut@gmail.com>, Ian Forbes <ian.forbes@broadcom.com>, Sasha Levin <sashal@kernel.org>, Shivani Agarwal <shivani.agarwal@broadcom.com>
+Message-ID: <20251224083652.614902-1-shivani.agarwal@broadcom.com>
+
+From: Zack Rusin <zack.rusin@broadcom.com>
+
+[ Upstream commit 5ac2c0279053a2c5265d46903432fb26ae2d0da2 ]
+
+Check that the resource which is converted to a surface exists before
+trying to use the cursor snooper on it.
+
+vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers
+because some svga commands accept SVGA3D_INVALID_ID to mean "no surface",
+unfortunately functions that accept the actual surfaces as objects might
+(and in case of the cursor snooper, do not) be able to handle null
+objects. Make sure that we validate not only the identifier (via the
+vmw_cmd_res_check) but also check that the actual resource exists before
+trying to do something with it.
+
+Fixes unchecked null-ptr reference in the snooping code.
+
+Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
+Fixes: c0951b797e7d ("drm/vmwgfx: Refactor resource management")
+Reported-by: Kuzey Arda Bulut <kuzeyardabulut@gmail.com>
+Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
+Cc: dri-devel@lists.freedesktop.org
+Reviewed-by: Ian Forbes <ian.forbes@broadcom.com>
+Link: https://lore.kernel.org/r/20250917153655.1968583-1-zack.rusin@broadcom.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+[Shivani: Modified to apply on v5.10.y-v6.1.y]
+Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+@@ -1520,6 +1520,7 @@ static int vmw_cmd_dma(struct vmw_privat
+ SVGA3dCmdHeader *header)
+ {
+ struct vmw_buffer_object *vmw_bo = NULL;
++ struct vmw_resource *res;
+ struct vmw_surface *srf = NULL;
+ VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdSurfaceDMA);
+ int ret;
+@@ -1555,18 +1556,24 @@ static int vmw_cmd_dma(struct vmw_privat
+
+ dirty = (cmd->body.transfer == SVGA3D_WRITE_HOST_VRAM) ?
+ VMW_RES_DIRTY_SET : 0;
+- ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
+- dirty, user_surface_converter,
+- &cmd->body.host.sid, NULL);
++ ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface, dirty,
++ user_surface_converter, &cmd->body.host.sid,
++ NULL);
+ if (unlikely(ret != 0)) {
+ if (unlikely(ret != -ERESTARTSYS))
+ VMW_DEBUG_USER("could not find surface for DMA.\n");
+ return ret;
+ }
+
+- srf = vmw_res_to_srf(sw_context->res_cache[vmw_res_surface].res);
++ res = sw_context->res_cache[vmw_res_surface].res;
++ if (!res) {
++ VMW_DEBUG_USER("Invalid DMA surface.\n");
++ return -EINVAL;
++ }
+
+- vmw_kms_cursor_snoop(srf, sw_context->fp->tfile, &vmw_bo->base, header);
++ srf = vmw_res_to_srf(res);
++ vmw_kms_cursor_snoop(srf, sw_context->fp->tfile, &vmw_bo->base,
++ header);
+
+ return 0;
+ }
fonts-add-charcount-field-to-font_desc.patch
parisc-sticore-avoid-hard-coding-built-in-font-charcount.patch
fbcon-avoid-using-fntcharcnt-and-hard-coded-built-in-font-charcount.patch
+drm-vmwgfx-fix-a-null-ptr-access-in-the-cursor-snooper.patch
+usb-xhci-move-link-chain-bit-quirk-checks-into-one-helper-function.patch
+usb-xhci-apply-the-link-chain-quirk-on-nec-isoc-endpoints.patch
--- /dev/null
+From linux-usb+bounces-32050-greg=kroah.com@vger.kernel.org Thu Jan 8 10:14:16 2026
+From: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Date: Thu, 8 Jan 2026 00:49:27 -0800
+Subject: usb: xhci: Apply the link chain quirk on NEC isoc endpoints
+To: stable@vger.kernel.org, gregkh@linuxfoundation.org
+Cc: mathias.nyman@intel.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, ajay.kaher@broadcom.com, alexey.makhalov@broadcom.com, vamsi-krishna.brahmajosyula@broadcom.com, yin.ding@broadcom.com, tapas.kundu@broadcom.com, Michal Pecio <michal.pecio@gmail.com>, Mathias Nyman <mathias.nyman@linux.intel.com>, Shivani Agarwal <shivani.agarwal@broadcom.com>
+Message-ID: <20260108084927.671785-3-shivani.agarwal@broadcom.com>
+
+From: Michal Pecio <michal.pecio@gmail.com>
+
+commit bb0ba4cb1065e87f9cc75db1fa454e56d0894d01 upstream.
+
+Two clearly different specimens of NEC uPD720200 (one with start/stop
+bug, one without) were seen to cause IOMMU faults after some Missed
+Service Errors. Faulting address is immediately after a transfer ring
+segment and patched dynamic debug messages revealed that the MSE was
+received when waiting for a TD near the end of that segment:
+
+[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0
+[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]
+[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
+
+It gets even funnier if the next page is a ring segment accessible to
+the HC. Below, it reports MSE in segment at ff1e8000, plows through a
+zero-filled page at ff1e9000 and starts reporting events for TRBs in
+page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
+
+[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
+[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
+[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
+[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.
+[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
+[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
+[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
+[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
+[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
+[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
+
+At some point completion events change from Isoch Buffer Overrun to
+Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
+
+[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
+[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
+[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
+[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
+[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
+
+It's possible that data from the isochronous device were written to
+random buffers of pending TDs on other endpoints (either IN or OUT),
+other devices or even other HCs in the same IOMMU domain.
+
+Lastly, an error from a different USB device on another HC. Was it
+caused by the above? I don't know, but it may have been. The disk
+was working without any other issues and generated PCIe traffic to
+starve the NEC of upstream BW and trigger those MSEs. The two HCs
+shared one x1 slot by means of a commercial "PCIe splitter" board.
+
+[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd
+[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
+[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00
+[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
+
+Fortunately, it appears that this ridiculous bug is avoided by setting
+the chain bit of Link TRBs on isochronous rings. Other ancient HCs are
+known which also expect the bit to be set and they ignore Link TRBs if
+it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
+
+The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports
+tens of MSEs per second and runs into the bug within seconds. Chaining
+Link TRBs allows the same workload to run for many minutes, many times.
+
+No negative side effects seen in UVC recording and UAC playback with a
+few devices at full speed, high speed and SuperSpeed.
+
+The problem doesn't reproduce on the newer Renesas uPD720201/uPD720202
+and on old Etron EJ168 and VIA VL805 (but the VL805 has other bug).
+
+[shorten line length of log snippets in commit messge -Mathias]
+
+Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20250306144954.3507700-14-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+[Shivani: Modified to apply on v5.10.y-v6.1.y]
+Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci.h | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1999,11 +1999,20 @@ static inline void xhci_write_64(struct
+ }
+
+
+-/* Link TRB chain should always be set on 0.95 hosts, and AMD 0.96 ISOC rings */
++/*
++ * Reportedly, some chapters of v0.95 spec said that Link TRB always has its chain bit set.
++ * Other chapters and later specs say that it should only be set if the link is inside a TD
++ * which continues from the end of one segment to the next segment.
++ *
++ * Some 0.95 hardware was found to misbehave if any link TRB doesn't have the chain bit set.
++ *
++ * 0.96 hardware from AMD and NEC was found to ignore unchained isochronous link TRBs when
++ * "resynchronizing the pipe" after a Missed Service Error.
++ */
+ static inline bool xhci_link_chain_quirk(struct xhci_hcd *xhci, enum xhci_ring_type type)
+ {
+ return (xhci->quirks & XHCI_LINK_TRB_QUIRK) ||
+- (type == TYPE_ISOC && (xhci->quirks & XHCI_AMD_0x96_HOST));
++ (type == TYPE_ISOC && (xhci->quirks & (XHCI_AMD_0x96_HOST | XHCI_NEC_HOST)));
+ }
+
+ /* xHCI debugging */
--- /dev/null
+From shivani.agarwal@broadcom.com Thu Jan 8 10:10:31 2026
+From: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Date: Thu, 8 Jan 2026 00:49:26 -0800
+Subject: usb: xhci: move link chain bit quirk checks into one helper function.
+To: stable@vger.kernel.org, gregkh@linuxfoundation.org
+Cc: mathias.nyman@intel.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, ajay.kaher@broadcom.com, alexey.makhalov@broadcom.com, vamsi-krishna.brahmajosyula@broadcom.com, yin.ding@broadcom.com, tapas.kundu@broadcom.com, Niklas Neronin <niklas.neronin@linux.intel.com>, Mathias Nyman <mathias.nyman@linux.intel.com>, Shivani Agarwal <shivani.agarwal@broadcom.com>
+Message-ID: <20260108084927.671785-2-shivani.agarwal@broadcom.com>
+
+From: Niklas Neronin <niklas.neronin@linux.intel.com>
+
+commit 7476a2215c07703db5e95efaa3fc5b9f957b9417 upstream.
+
+Older 0.95 xHCI hosts and some other specific newer hosts require the
+chain bit to be set for Link TRBs even if the link TRB is not in the
+middle of a transfer descriptor (TD).
+
+move the checks for all those cases into one xhci_link_chain_quirk()
+function to clean up and avoid code duplication.
+
+No functional changes.
+
+[skip renaming chain_links flag, reword commit message -Mathias]
+
+Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20240626124835.1023046-10-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+[Shivani: Modified to apply on v5.10.y-v6.1.y]
+Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mem.c | 10 ++--------
+ drivers/usb/host/xhci-ring.c | 8 ++------
+ drivers/usb/host/xhci.h | 7 +++++--
+ 3 files changed, 9 insertions(+), 16 deletions(-)
+
+--- a/drivers/usb/host/xhci-mem.c
++++ b/drivers/usb/host/xhci-mem.c
+@@ -133,10 +133,7 @@ static void xhci_link_rings(struct xhci_
+ if (!ring || !first || !last)
+ return;
+
+- /* Set chain bit for 0.95 hosts, and for isoc rings on AMD 0.96 host */
+- chain_links = !!(xhci_link_trb_quirk(xhci) ||
+- (ring->type == TYPE_ISOC &&
+- (xhci->quirks & XHCI_AMD_0x96_HOST)));
++ chain_links = xhci_link_chain_quirk(xhci, ring->type);
+
+ next = ring->enq_seg->next;
+ xhci_link_segments(ring->enq_seg, first, ring->type, chain_links);
+@@ -326,10 +323,7 @@ static int xhci_alloc_segments_for_ring(
+ struct xhci_segment *prev;
+ bool chain_links;
+
+- /* Set chain bit for 0.95 hosts, and for isoc rings on AMD 0.96 host */
+- chain_links = !!(xhci_link_trb_quirk(xhci) ||
+- (type == TYPE_ISOC &&
+- (xhci->quirks & XHCI_AMD_0x96_HOST)));
++ chain_links = xhci_link_chain_quirk(xhci, type);
+
+ prev = xhci_segment_alloc(xhci, cycle_state, max_packet, flags);
+ if (!prev)
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -230,9 +230,7 @@ static void inc_enq(struct xhci_hcd *xhc
+ * AMD 0.96 host, carry over the chain bit of the previous TRB
+ * (which may mean the chain bit is cleared).
+ */
+- if (!(ring->type == TYPE_ISOC &&
+- (xhci->quirks & XHCI_AMD_0x96_HOST)) &&
+- !xhci_link_trb_quirk(xhci)) {
++ if (!xhci_link_chain_quirk(xhci, ring->type)) {
+ next->link.control &= cpu_to_le32(~TRB_CHAIN);
+ next->link.control |= cpu_to_le32(chain);
+ }
+@@ -3138,9 +3136,7 @@ static int prepare_ring(struct xhci_hcd
+ /* If we're not dealing with 0.95 hardware or isoc rings
+ * on AMD 0.96 host, clear the chain bit.
+ */
+- if (!xhci_link_trb_quirk(xhci) &&
+- !(ep_ring->type == TYPE_ISOC &&
+- (xhci->quirks & XHCI_AMD_0x96_HOST)))
++ if (!xhci_link_chain_quirk(xhci, ep_ring->type))
+ ep_ring->enqueue->link.control &=
+ cpu_to_le32(~TRB_CHAIN);
+ else
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1998,9 +1998,12 @@ static inline void xhci_write_64(struct
+ lo_hi_writeq(val, regs);
+ }
+
+-static inline int xhci_link_trb_quirk(struct xhci_hcd *xhci)
++
++/* Link TRB chain should always be set on 0.95 hosts, and AMD 0.96 ISOC rings */
++static inline bool xhci_link_chain_quirk(struct xhci_hcd *xhci, enum xhci_ring_type type)
+ {
+- return xhci->quirks & XHCI_LINK_TRB_QUIRK;
++ return (xhci->quirks & XHCI_LINK_TRB_QUIRK) ||
++ (type == TYPE_ISOC && (xhci->quirks & XHCI_AMD_0x96_HOST));
+ }
+
+ /* xHCI debugging */
projects / thirdparty / kernel / stable-queue.git / commitdiff
