AZL-97257

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

ALSA: usb-audio: fix OOB write on Type II inbound URBs

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

prepareinboundurb() 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. preparesilenturb() and prepareplaybackurb() bound their fill loops by ctx->buffer_size, so only capture is affected.

fmttype comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hwparams 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 __asanmemcpy dummytimer hrtimerrunsoftirq Allocated by task 166: usballoccoherent sndusbendpointsetparams The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0)

Compute buffersize after the delimiter packet has been accounted for, and bound the fill loop by buffersize, as preparesilenturb() 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