CVE-2026-74682ALSA: usb-audio: fix OOB write on Type II inbound URBs
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: u->packets = urb_packs; u->buffer_size = maxsize * u->packets; if (fmt->fmt_type == UAC_FORMAT_TYPE_II) u->packets++; /* for transfer delimiter */ u->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: offs = 0; for (i = 0; i < urb_ctx->packets; i++) { urb->iso_frame_desc[i].offset = offs; urb->iso_frame_desc[i].length = ep->curpacksize; offs += ep->curpacksize; } urb->transfer_buffer_length = offs; urb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Aug 22, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | 8fdff6a319e7dac757c558bd283dc4577e68cde7 builds before 6af5f29af7711233ae68d3b25c15d67478468900; from 8fdff6a319e7dac757c558bd283dc4577e68cde7 before f1fbb50b99311b35c2e85cc70341d62082dca4b5; from 8fdff6a319e7dac757c558bd283dc4577e68cde7 before 137bf034740e5a2734794908d0aff1e0bd7cee6e; from 8fdff6a319e7dac757c558bd283dc4577e68cde7 before 6607f85242577f33d4540a0d1f4a6137f5367058; from 8fdff6a319e7dac757c558bd283dc4577e68cde7 before ca22c94bdfc22c564ca2e11c87ba4d17ebeaaa9a; 8fdff6a319e7dac757c558bd283dc4577e68cde7 builds before 0a235379825e1a6194e43861ee6658e5fc35686d; from 8fdff6a319e7dac757c558bd283dc4577e68cde7 before d3ed4e6321bb453757044cb9e5ecb30a33f04903; from 8fdff6a319e7dac757c558bd283dc4577e68cde7 before 69ee44e1a23be62318189dc4b37fa4ad94053269 | CNA record |
References
- https://git.kernel.org/stable/c/6af5f29af7711233ae68d3b25c15d67478468900
- https://git.kernel.org/stable/c/f1fbb50b99311b35c2e85cc70341d62082dca4b5
- https://git.kernel.org/stable/c/137bf034740e5a2734794908d0aff1e0bd7cee6e
- https://git.kernel.org/stable/c/6607f85242577f33d4540a0d1f4a6137f5367058
- https://git.kernel.org/stable/c/ca22c94bdfc22c564ca2e11c87ba4d17ebeaaa9a
- https://git.kernel.org/stable/c/0a235379825e1a6194e43861ee6658e5fc35686d
- https://git.kernel.org/stable/c/d3ed4e6321bb453757044cb9e5ecb30a33f04903
- https://git.kernel.org/stable/c/69ee44e1a23be62318189dc4b37fa4ad94053269
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.