{"cve":"CVE-2026-90015","nvd":{"published":"2026-09-16T11:17:14.210","modified":"2026-10-19T09:18:49.393","status":"Received","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: fix lost bounce buffers on TDs spanning several ring segments\n\nWhen a TD reaches a link TRB with data that is not aligned to the\nendpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail\nthrough the bounce buffer of the ring segment holding that link TRB.\nxhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers,\ncopies the data back into the URB's buffer.\n\nThe enqueue path records the segment that was bounced in td->bounce_seg,\nunder the assumption that a TD never spans more than two ring segments.\nThat assumption does not hold: a TD large enough to span three or more\nsegments crosses several link TRBs and can be bounced at each of them.\nOnly the last one survives in td->bounce_seg, so every earlier bounce\nbuffer is neither copied back nor DMA unmapped.\n\nThe URB still completes with actual_length equal to the requested length\nand no error, so the transfer looks successful while a wMaxPacketSize\nsized hole in the destination buffer silently keeps its previous\ncontents. It also leaks a DMA mapping per dropped bounce.\n\nAny sufficiently large and fragmented bulk transfer can hit this. It was\nfound with a USB mass storage device behind xHCI backing a dm-verity\ntarget with 512 byte hash blocks, where the stale data is detected rather\nthan silently consumed. The device enumerates as SuperSpeed, so\nwMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash\nblock. verity_prefetch_io() makes the block layer merge hundreds of them\ninto a single request of up to 512 scatterlist entries of 512 bytes each.\nAt 256 TRBs per ring segment such a TD spans three segments, and every\nsegment boundary falls on an odd multiple of 512, i.e. unaligned to\nwMaxPacketSize. dm-bufio then caches a hash block holding stale data and\ndm-verity declares the metadata block corrupted:\n\n  device-mapper: verity: 8:2: metadata block 10850 is corrupted\n\nA reproducer running this under qemu is available at\nhttps://github.com/baloo/xhci-verity\n\nThe bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs)\nalready lives on the ring segment, so there is nothing extra to track.\nKeep recording the last bounced segment in td->bounce_seg and, on\ncompletion, walk the segments from td->start_seg up to it, unmapping\nevery segment that still has a pending bounce.\n\nStopping at td->bounce_seg rather than td->end_seg matters: a bounce\nimplies the TD continues past that segment's link TRB, so bounce_seg is\nalways strictly before end_seg, and a later TD may already have started\nin end_seg and been bounced there. Walking that far would copy a foreign\nbounce buffer into this URB and unmap it twice. It also keeps the walk\ncorrect if a TD ever wraps the whole ring so that end_seg == start_seg.\n\n[mn: Add ring->num_segs check to prevent unlikely infinite for loop.]","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/3c9a2b5a4f1183696f02ac280ced1d34afb409b1","https://git.kernel.org/stable/c/43239fc6dfb62c50ae1b9c0e82bac0f8cd2e285c","https://git.kernel.org/stable/c/7236bbd2cb7d9fc0eda896bbd34790341e2a4377","https://git.kernel.org/stable/c/a1629dfb011446d02905778f6df19f14c5f4f3b3","https://git.kernel.org/stable/c/c8124b28f12dbdd126118e63d0ebf8093a01fb81"],"products":[],"source":"nvd","synced_at":"2026-10-19T22:54:41.405518556+00:00"},"epss":{"cve":"CVE-2026-90015","score":0.00216,"percentile":0.11953,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}