CVE-2025-22022

In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Apply the link chain quirk on NEC isoc endpoints 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 ne ---truncated---
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.14:*:*:*:*:*:*:*

History

28 Oct 2025, 20:06

Type Values Removed Values Added
References () https://git.kernel.org/stable/c/061a1683bae6ef56ab8fa392725ba7495515cd1d - () https://git.kernel.org/stable/c/061a1683bae6ef56ab8fa392725ba7495515cd1d - Patch
References () https://git.kernel.org/stable/c/43a18225150ce874d23b37761c302a5dffee1595 - () https://git.kernel.org/stable/c/43a18225150ce874d23b37761c302a5dffee1595 - Patch
References () https://git.kernel.org/stable/c/a4931d9fb99eb5462f3eaa231999d279c40afb21 - () https://git.kernel.org/stable/c/a4931d9fb99eb5462f3eaa231999d279c40afb21 - Patch
References () https://git.kernel.org/stable/c/bb0ba4cb1065e87f9cc75db1fa454e56d0894d01 - () https://git.kernel.org/stable/c/bb0ba4cb1065e87f9cc75db1fa454e56d0894d01 - Patch
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Aplicar la peculiaridad de la cadena de enlace en los endpoints isoc de NEC Se observó que dos ejemplares claramente diferentes de NEC uPD720200 (uno con un error de inicio/detención y otro sin él) causaban fallas de IOMMU después de algunos errores de servicio perdido. La dirección con fallas se encuentra inmediatamente después de un segmento de anillo de transferencia y los mensajes de depuración dinámica parcheados revelaron que se recibió el MSE cuando se esperaba un TD cerca del final de ese segmento: [1.041954] xhci_hcd: Error de intervalo de servicio faltante para la ranura 1 ep 2 se esperaba TD DMA ffa08fe0 [1.042120] xhci_hcd: AMD-Vi: Evento registrado [IO_PAGE_FAULT dominio=0x0005 dirección=0xffa09000 indicadores=0x0000] [1.042146] xhci_hcd: AMD-Vi: Evento registrado [IO_PAGE_FAULT dominio=0x0005 dirección=0xffa09040 indicadores=0x0000] Se vuelve aún más divertido si la siguiente página es un segmento de anillo accesible para el HC. A continuación, informa MSE en el segmento en ff1e8000, recorre una página llena de ceros en ff1e9000 y comienza a informar eventos para TRB en la página en ff1ea000 cada microtrama, en lugar de saltar al segmento ff1e6000. [7.041671] xhci_hcd: Error de intervalo de servicio perdido para la ranura 1 ep 2 esperada TD DMA ff1e8fe0 [7.041999] xhci_hcd: Error de intervalo de servicio perdido para la ranura 1 ep 2 esperada TD DMA ff1e8fe0 [7.042011] xhci_hcd: ADVERTENCIA: evento de desbordamiento de búfer para la ranura 1 ep 2 en el endpoint [7.042028] xhci_hcd: Se omitieron todos los TD para la ranura 1 ep 2. Borrar el indicador de omisión. [ 7.042134] xhci_hcd: ADVERTENCIA: evento de desbordamiento de búfer para la ranura 1 ep 2 en el endpoint [ 7.042138] xhci_hcd: ERROR Evento de transferencia TRB DMA ptr no forma parte del TD actual ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Buscando evento-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: ADVERTENCIA: evento de desbordamiento de búfer para la ranura 1 ep 2 en el endpoint [ 7.042262] xhci_hcd: ERROR Evento de transferencia TRB DMA ptr no forma parte del TD actual ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Buscando evento-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 En algún punto, los eventos de finalización cambian de Desbordamiento de búfer de isocrono a Paquete corto y el HC finalmente encuentra una falta de coincidencia de bits de ciclo en ff1ec000. [ 7.098130] xhci_hcd: ERROR El punto de transferencia TRB DMA del evento no forma parte del TD actual ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Buscando el punto de transferencia event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR El punto de transferencia TRB DMA del evento no forma parte del TD actual ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Buscando el punto de transferencia event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [7.098379] xhci_hcd: Evento de saturación en la ranura 1, episodio 2. Es posible que los datos del dispositivo isócrono se escribieran en búferes aleatorios de TD pendientes en otros endpoints (de entrada o de salida), otros dispositivos o incluso otros HC en el mismo dominio IOMMU. Por último, se produjo un error de un dispositivo USB diferente en otro HC. ¿Fue causado por lo anterior? No lo sé, pero podría haber sido. El disco funcionaba sin problemas y generó tráfico PCIe que privó al NEC de BW ascendente y activó esos MSE. Los dos HC compartían una ranura x1 mediante una placa divisora PCIe comercial. [ 7.162604] usb 10-2: restablecer el dispositivo USB SuperSpeed número 3 usando xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Resultado: 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] Error de E/S, dev sdb, sector 67284480 op 0x0:(READ) ---truncated---
First Time Linux linux Kernel
Linux
CPE cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.14:*:*:*:*:*:*:*
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 7.8
CWE CWE-787

16 Apr 2025, 11:15

Type Values Removed Values Added
New CVE

Information

Published : 2025-04-16 11:15

Updated : 2025-10-28 20:06


NVD link : CVE-2025-22022

Mitre link : CVE-2025-22022

CVE.ORG link : CVE-2025-22022


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-787

Out-of-bounds Write