From: Greg Kroah-Hartman Date: Thu, 8 Jan 2026 13:32:38 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v6.1.160~35 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=017de13109f92192c5f601f05c17c37456a7753e;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: drm-vmwgfx-fix-a-null-ptr-access-in-the-cursor-snooper.patch usb-xhci-apply-the-link-chain-quirk-on-nec-isoc-endpoints.patch usb-xhci-move-link-chain-bit-quirk-checks-into-one-helper-function.patch --- diff --git a/queue-5.10/drm-vmwgfx-fix-a-null-ptr-access-in-the-cursor-snooper.patch b/queue-5.10/drm-vmwgfx-fix-a-null-ptr-access-in-the-cursor-snooper.patch new file mode 100644 index 0000000000..8447f0a390 --- /dev/null +++ b/queue-5.10/drm-vmwgfx-fix-a-null-ptr-access-in-the-cursor-snooper.patch @@ -0,0 +1,80 @@ +From stable+bounces-203358-greg=kroah.com@vger.kernel.org Wed Dec 24 09:57:13 2025 +From: Shivani Agarwal +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 , Ian Forbes , Sasha Levin , Shivani Agarwal +Message-ID: <20251224083652.614902-1-shivani.agarwal@broadcom.com> + +From: Zack Rusin + +[ 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 +Fixes: c0951b797e7d ("drm/vmwgfx: Refactor resource management") +Reported-by: Kuzey Arda Bulut +Cc: Broadcom internal kernel review list +Cc: dri-devel@lists.freedesktop.org +Reviewed-by: Ian Forbes +Link: https://lore.kernel.org/r/20250917153655.1968583-1-zack.rusin@broadcom.com +Signed-off-by: Sasha Levin +[Shivani: Modified to apply on v5.10.y-v6.1.y] +Signed-off-by: Shivani Agarwal +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.10/series b/queue-5.10/series index b8b50f167b..36865ed8f2 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -342,3 +342,6 @@ console-delete-dummy-con_font_set-and-con_font_default-callback-implementations. 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 diff --git a/queue-5.10/usb-xhci-apply-the-link-chain-quirk-on-nec-isoc-endpoints.patch b/queue-5.10/usb-xhci-apply-the-link-chain-quirk-on-nec-isoc-endpoints.patch new file mode 100644 index 0000000000..fe35dd0a48 --- /dev/null +++ b/queue-5.10/usb-xhci-apply-the-link-chain-quirk-on-nec-isoc-endpoints.patch @@ -0,0 +1,116 @@ +From linux-usb+bounces-32050-greg=kroah.com@vger.kernel.org Thu Jan 8 10:14:16 2026 +From: Shivani Agarwal +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 , Mathias Nyman , Shivani Agarwal +Message-ID: <20260108084927.671785-3-shivani.agarwal@broadcom.com> + +From: Michal Pecio + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20250306144954.3507700-14-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +[Shivani: Modified to apply on v5.10.y-v6.1.y] +Signed-off-by: Shivani Agarwal +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ diff --git a/queue-5.10/usb-xhci-move-link-chain-bit-quirk-checks-into-one-helper-function.patch b/queue-5.10/usb-xhci-move-link-chain-bit-quirk-checks-into-one-helper-function.patch new file mode 100644 index 0000000000..9a1307ab02 --- /dev/null +++ b/queue-5.10/usb-xhci-move-link-chain-bit-quirk-checks-into-one-helper-function.patch @@ -0,0 +1,103 @@ +From shivani.agarwal@broadcom.com Thu Jan 8 10:10:31 2026 +From: Shivani Agarwal +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 , Mathias Nyman , Shivani Agarwal +Message-ID: <20260108084927.671785-2-shivani.agarwal@broadcom.com> + +From: Niklas Neronin + +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 +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20240626124835.1023046-10-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +[Shivani: Modified to apply on v5.10.y-v6.1.y] +Signed-off-by: Shivani Agarwal +Signed-off-by: Greg Kroah-Hartman +--- + 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 */