From: Takashi Iwai <tiwai@suse.de>
To: Xiang Mei <xmei5@asu.edu>
Cc: tiwai@suse.com, perex@perex.cz, linux-sound@vger.kernel.org,
linux-kernel@vger.kernel.org, co+be8fa7ea6f77fdce@bugs.sh,
stable@vger.kernel.org
Subject: Re: [PATCH] ALSA: line6: reject oversized playback packets
Date: Mon, 28 Sep 2026 13:11:21 +0200 [thread overview]
Message-ID: <877bk57hra.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260918234014.1318325-1-xmei5@asu.edu>
On Sat, 19 Sep 2026 01:40:14 +0200,
Xiang Mei wrote:
>
> Each playback URB is handed a slice of out.buffer that is exactly
> LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT
> endpoint, but the number of bytes written into that slice is never
> compared against it.
>
> submit_audio_out_urb() takes the frame count from prev_fsize, which
> audio_in_callback() derived from the *IN* endpoint's received packet
> length, and rescales it with the playback frame size; when prev_fsize is
> still zero it synthesizes a length from the sample rate instead. On a
> device declaring a large IN wMaxPacketSize and a small OUT
> wMaxPacketSize, the resulting memcpy(), or the memset() when the
> playback stream is idle, runs past its slice and, as the reproducer
> below shows, beyond the allocation.
>
> usb_submit_urb() is not a backstop. max_packet_size_out comes from
> usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize,
> while USB core validates a high-speed isochronous length against that
> base scaled by usb_endpoint_maxp_mult(). A length of up to three times
> the allocated slice is therefore accepted, and even a rejected URB is
> only rejected after the write.
>
> Reject a packet that does not fit the slice the driver allocated for it.
> Clamping it instead would silently shorten the capture-derived rate
> feedback and desynchronize the two streams.
>
> BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229)
> Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002
> Workqueue: events line6_startup_work
> Call Trace:
> __asan_memcpy (mm/kasan/shadow.c:106)
> submit_audio_out_urb (sound/usb/line6/playback.c:229)
> line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291)
> line6_stream_start (sound/usb/line6/pcm.c:194)
> line6_pcm_acquire (sound/usb/line6/pcm.c:337)
> line6_startup_work (sound/usb/line6/driver.c:728)
> process_one_work (kernel/workqueue.c:3396)
> worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
> kthread (kernel/kthread.c:436)
> ret_from_fork (arch/x86/kernel/process.c:158)
> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
>
> The buggy address belongs to the object at ffff888100bbd400
> which belongs to the cache kmalloc-256 of size 256
> The buggy address is located 0 bytes inside of
> allocated 256-byte region [ffff888100bbd400, ffff888100bbd500)
>
> Cc: stable@vger.kernel.org
> Fixes: 7a0f55aeeb8f ("ALSA: line6: Support assymetrical in/out configurations")
> Reported-by: <co+be8fa7ea6f77fdce@bugs.sh>
> Assisted-by: LLM
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
Applied now. Thanks.
Takashi
prev parent reply other threads:[~2026-09-28 11:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 23:40 [PATCH] ALSA: line6: reject oversized playback packets Xiang Mei
2026-09-28 11:11 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877bk57hra.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=co+be8fa7ea6f77fdce@bugs.sh \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=stable@vger.kernel.org \
--cc=tiwai@suse.com \
--cc=xmei5@asu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.