mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] ALSA: line6: reject oversized playback packets
@ 2026-09-18 23:40 Xiang Mei
  2026-09-28 11:11 ` Takashi Iwai
  0 siblings, 1 reply; 2+ messages in thread
From: Xiang Mei @ 2026-09-18 23:40 UTC (permalink / raw)
  To: tiwai, perex, linux-sound
  Cc: linux-kernel, co+be8fa7ea6f77fdce, stable, Xiang Mei

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>
---
 sound/usb/line6/playback.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/usb/line6/playback.c b/sound/usb/line6/playback.c
index 7ebaf125f969..aa6ddf8746a0 100644
--- a/sound/usb/line6/playback.c
+++ b/sound/usb/line6/playback.c
@@ -182,6 +182,13 @@ static int submit_audio_out_urb(struct snd_line6_pcm *line6pcm)
 
 		fsize *= bytes_per_frame;
 
+		if (fsize > line6pcm->max_packet_size_out) {
+			dev_err(line6pcm->line6->ifcdev,
+				"playback packet too large: %d > %d\n",
+				fsize, line6pcm->max_packet_size_out);
+			return -EMSGSIZE;
+		}
+
 		fout->offset = urb_size;
 		fout->length = fsize;
 		urb_size += fsize;
-- 
2.43.0


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] ALSA: line6: reject oversized playback packets
  2026-09-18 23:40 [PATCH] ALSA: line6: reject oversized playback packets Xiang Mei
@ 2026-09-28 11:11 ` Takashi Iwai
  0 siblings, 0 replies; 2+ messages in thread
From: Takashi Iwai @ 2026-09-28 11:11 UTC (permalink / raw)
  To: Xiang Mei
  Cc: tiwai, perex, linux-sound, linux-kernel, co+be8fa7ea6f77fdce, stable

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-09-28 11:11 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-18 23:40 [PATCH] ALSA: line6: reject oversized playback packets Xiang Mei
2026-09-28 11:11 ` Takashi Iwai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®