CVE-2025-22022

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
16/04/2025
Last modified:
16/04/2025

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Apply the link chain quirk on NEC isoc endpoints<br /> <br /> Two clearly different specimens of NEC uPD720200 (one with start/stop<br /> bug, one without) were seen to cause IOMMU faults after some Missed<br /> Service Errors. Faulting address is immediately after a transfer ring<br /> segment and patched dynamic debug messages revealed that the MSE was<br /> received when waiting for a TD near the end of that segment:<br /> <br /> [ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0<br /> [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]<br /> [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]<br /> <br /> It gets even funnier if the next page is a ring segment accessible to<br /> the HC. Below, it reports MSE in segment at ff1e8000, plows through a<br /> zero-filled page at ff1e9000 and starts reporting events for TRBs in<br /> page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.<br /> <br /> [ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0<br /> [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0<br /> [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint<br /> [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.<br /> [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint<br /> [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31<br /> [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint<br /> [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31<br /> [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> <br /> At some point completion events change from Isoch Buffer Overrun to<br /> Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.<br /> <br /> [ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13<br /> [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13<br /> [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2<br /> <br /> It&amp;#39;s possible that data from the isochronous device were written to<br /> random buffers of pending TDs on other endpoints (either IN or OUT),<br /> other devices or even other HCs in the same IOMMU domain.<br /> <br /> Lastly, an error from a different USB device on another HC. Was it<br /> caused by the above? I don&amp;#39;t know, but it may have been. The disk<br /> was working without any other issues and generated PCIe traffic to<br /> starve the NEC of upstream BW and trigger those MSEs. The two HCs<br /> shared one x1 slot by means of a commercial "PCIe splitter" board.<br /> <br /> [ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd<br /> [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s<br /> [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00<br /> [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0<br /> <br /> Fortunately, it appears that this ridiculous bug is avoided by setting<br /> the chain bit of Link TRBs on isochronous rings. Other ancient HCs are<br /> known which also expect the bit to be set and they ignore Link TRBs if<br /> it&amp;#39;s not. Reportedly, 0.95 spec guaranteed that the bit is set.<br /> <br /> The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports<br /> tens of MSEs per second and runs into the bug within seconds. Chaining<br /> Link TRBs allows the same workload to run for many minutes, many times.<br /> <br /> No ne<br /> ---truncated---

Impact