CVE-2026-74682
ALSA: usb-audio: fix OOB write on Type II inbound URBs
Description
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 <[email protected]>
INFO
Published Date :
Aug. 22, 2026, 4:16 p.m.
Last Modified :
Aug. 22, 2026, 4:16 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products
The following products are affected by CVE-2026-74682
vulnerability.
Even if cvefeed.io is aware of the exact versions of the
products
that
are
affected, the information is not represented in the table below.
No affected product recoded yet
Solution
- Compute buffer_size after accounting for the delimiter packet.
- Bound fill loops by buffer_size.
- Apply the provided kernel patch.
- Update the Linux kernel.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-74682.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-74682 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-74682
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-74682 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-74682 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Aug. 22, 2026
Action Type Old Value New Value Added Affected [{'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': '6af5f29af7711233ae68d3b25c15d67478468900', 'versionType': 'git'}, {'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': 'f1fbb50b99311b35c2e85cc70341d62082dca4b5', 'versionType': 'git'}, {'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': '137bf034740e5a2734794908d0aff1e0bd7cee6e', 'versionType': 'git'}, {'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': '6607f85242577f33d4540a0d1f4a6137f5367058', 'versionType': 'git'}, {'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': 'ca22c94bdfc22c564ca2e11c87ba4d17ebeaaa9a', 'versionType': 'git'}, {'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': '0a235379825e1a6194e43861ee6658e5fc35686d', 'versionType': 'git'}, {'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': 'd3ed4e6321bb453757044cb9e5ecb30a33f04903', 'versionType': 'git'}, {'status': 'affected', 'version': '8fdff6a319e7dac757c558bd283dc4577e68cde7', 'lessThan': '69ee44e1a23be62318189dc4b37fa4ad94053269', 'versionType': 'git'}], 'programFiles': ['sound/usb/endpoint.c'], 'defaultStatus': 'unaffected'}, {'repo': 'https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git', 'vendor': 'Linux', 'product': 'Linux', 'versions': [{'status': 'affected', 'version': '3.5'}, {'status': 'unaffected', 'version': '0', 'lessThan': '3.5', 'versionType': 'semver'}, {'status': 'unaffected', 'version': '5.10.265', 'versionType': 'semver', 'lessThanOrEqual': '5.10.*'}, {'status': 'unaffected', 'version': '5.15.216', 'versionType': 'semver', 'lessThanOrEqual': '5.15.*'}, {'status': 'unaffected', 'version': '6.1.183', 'versionType': 'semver', 'lessThanOrEqual': '6.1.*'}, {'status': 'unaffected', 'version': '6.6.152', 'versionType': 'semver', 'lessThanOrEqual': '6.6.*'}, {'status': 'unaffected', 'version': '6.12.104', 'versionType': 'semver', 'lessThanOrEqual': '6.12.*'}, {'status': 'unaffected', 'version': '6.18.45', 'versionType': 'semver', 'lessThanOrEqual': '6.18.*'}, {'status': 'unaffected', 'version': '7.1.9', 'versionType': 'semver', 'lessThanOrEqual': '7.1.*'}, {'status': 'unaffected', 'version': '7.2', 'versionType': 'original_commit_for_fix', 'lessThanOrEqual': '*'}], 'programFiles': ['sound/usb/endpoint.c'], 'defaultStatus': 'affected'}] Added Description 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 <[email protected]> Added Reference https://git.kernel.org/stable/c/0a235379825e1a6194e43861ee6658e5fc35686d Added Reference https://git.kernel.org/stable/c/137bf034740e5a2734794908d0aff1e0bd7cee6e Added Reference https://git.kernel.org/stable/c/6607f85242577f33d4540a0d1f4a6137f5367058 Added Reference https://git.kernel.org/stable/c/69ee44e1a23be62318189dc4b37fa4ad94053269 Added Reference https://git.kernel.org/stable/c/6af5f29af7711233ae68d3b25c15d67478468900 Added Reference https://git.kernel.org/stable/c/ca22c94bdfc22c564ca2e11c87ba4d17ebeaaa9a Added Reference https://git.kernel.org/stable/c/d3ed4e6321bb453757044cb9e5ecb30a33f04903 Added Reference https://git.kernel.org/stable/c/f1fbb50b99311b35c2e85cc70341d62082dca4b5