---
id: CVE-2026-90015
title: |-
  In the Linux kernel, the following vulnerability has been resolved:

  xhci: fix lost bounce buffers on TDs spanning several ring segments

  When a TD reaches a link TRB with data that is not aligned to the
  endpoint's wMaxPacketSize, xhci_a…
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  xhci: fix lost bounce buffers on TDs spanning several ring segments

  When a TD reaches a link TRB with data that is not aligned to the
  endpoint's wMaxPacketSize, xhci_a…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    c8124b28f12dbdd126118e63d0ebf8093a01fb81
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    e04d5304a248e5d2a7f4faa87541644bdd320cfb
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    a1629dfb011446d02905778f6df19f14c5f4f3b3
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    43239fc6dfb62c50ae1b9c0e82bac0f8cd2e285c
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    3c9a2b5a4f1183696f02ac280ced1d34afb409b1
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    efaab8938fb92979be6df359f7d1a43fb7e4717d
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    7236bbd2cb7d9fc0eda896bbd34790341e2a4377
  - >-
    Linux >= f9c589e142d04b8a19eb382162f804d17102b5ed <
    ff44dfb03a293bf30e31f98772a1dd316a6071d1
  - Linux 4.8
published: '2026-09-16'
updated: '2026-09-16'
sourceUpdated: '2026-09-16T11:17:14.210'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-90015'
references:
  - url: 'https://git.kernel.org/stable/c/3c9a2b5a4f1183696f02ac280ced1d34afb409b1'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/43239fc6dfb62c50ae1b9c0e82bac0f8cd2e285c'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/7236bbd2cb7d9fc0eda896bbd34790341e2a4377'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/a1629dfb011446d02905778f6df19f14c5f4f3b3'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/c8124b28f12dbdd126118e63d0ebf8093a01fb81'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/e04d5304a248e5d2a7f4faa87541644bdd320cfb'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/efaab8938fb92979be6df359f7d1a43fb7e4717d'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/ff44dfb03a293bf30e31f98772a1dd316a6071d1'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-16T10:53:53.940Z'
epss: 0.0021
epssPercentile: 0.10069
---

## Overview

In the Linux kernel, the following vulnerability has been resolved:

xhci: fix lost bounce buffers on TDs spanning several ring segments

When a TD reaches a link TRB with data that is not aligned to the
endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail
through the bounce buffer of the ring segment holding that link TRB.
xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers,
copies the data back into the URB's buffer.

The enqueue path records the segment that was bounced in td->bounce_seg,
under the assumption that a TD never spans more than two ring segments.
That assumption does not hold: a TD large enough to span three or more
segments crosses several link TRBs and can be bounced at each of them.
Only the last one survives in td->bounce_seg, so every earlier bounce
buffer is neither copied back nor DMA unmapped.

The URB still completes with actual_length equal to the requested length
and no error, so the transfer looks successful while a wMaxPacketSize
sized hole in the destination buffer silently keeps its previous
contents. It also leaks a DMA mapping per dropped bounce.

Any sufficiently large and fragmented bulk transfer can hit this. It was
found with a USB mass storage device behind xHCI backing a dm-verity
target with 512 byte hash blocks, where the stale data is detected rather
than silently consumed. The device enumerates as SuperSpeed, so
wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash
block. verity_prefetch_io() makes the block layer merge hundreds of them
into a single request of up to 512 scatterlist entries of 512 bytes each.
At 256 TRBs per ring segment such a TD spans three segments, and every
segment boundary falls on an odd multiple of 512, i.e. unaligned to
wMaxPacketSize. dm-bufio then caches a hash block holding stale data and
dm-verity declares the metadata block corrupted:

  device-mapper: verity: 8:2: metadata block 10850 is corrupted

A reproducer running this under qemu is available at
https://github.com/baloo/xhci-verity

The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs)
already lives on the ring segment, so there is nothing extra to track.
Keep recording the last bounced segment in td->bounce_seg and, on
completion, walk the segments from td->start_seg up to it, unmapping
every segment that still has a pending bounce.

Stopping at td->bounce_seg rather than td->end_seg matters: a bounce
implies the TD continues past that segment's link TRB, so bounce_seg is
always strictly before end_seg, and a later TD may already have started
in end_seg and been bounced there. Walking that far would copy a foreign
bounce buffer into this URB and unmap it twice. It also keeps the walk
correct if a TD ever wraps the whole ring so that end_seg == start_seg.

[mn: Add ring->num_segs check to prevent unlikely infinite for loop.]

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.