From: Takashi Iwai <tiwai@suse.de>
To: Gichoon Han <gichoon.han@samsung.com>
Cc: Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
Sinan Turunc <enscrpt@pm.me>, Edward Adam Davis <eadavis@qq.com>,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] ALSA: usb-audio: Drop capture packets with bogus actual_length
Date: Tue, 10 Nov 2026 11:46:53 +0100 [thread overview]
Message-ID: <87se19ufoi.wl-tiwai@suse.de> (raw)
In-Reply-To: <20261110060021.2146383-1-gichoon.han@samsung.com>
On Tue, 10 Nov 2026 07:00:21 +0100,
Gichoon Han wrote:
>
> retire_capture_urb() copies urb->iso_frame_desc[i].actual_length bytes
> out of urb->transfer_buffer at the packet's offset, but never checks
> that value against the requested packet length. A host controller
> reporting more data than requested makes memcpy() read past the end
> of the URB transfer buffer.
>
> Commit 06be918062ad ("ALSA: usb-audio: Bound packet copies by the PCM
> buffer size") clamps the count to the PCM ring buffer size, which
> protects the destination. The source slot is only ep->curpacksize
> bytes per packet, though, so the over-read remains.
>
> This was hit on an ARM32 system (vendor 5.4 kernel; the code path is
> unchanged in mainline) with a full-speed UAC1 microphone behind a
> high-speed hub, i.e. the EHCI siTD path. sitd_complete() computes
> actual_length as desc->length - SITD_LENGTH(t); the controller
> reported a remaining length larger than the programmed one, the value
> wrapped to ~4G, and the capture copy faulted on the first unmapped
> page after the URB buffer:
>
> Unable to handle kernel paging request at virtual address e8756000
> Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> r3 : 00000000 r2 : 0001e700 r1 : e8756000 r0 : e878fc80
> Code: ba000002 f5d1f03c f5d1f05c f5d1f07c (e8b151f8)
>
> A packet can never legitimately carry more than its requested length,
> so warn and skip it instead of copying.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gichoon Han <gichoon.han@samsung.com>
> ---
> Compile-tested only on linux-next. The crash was observed in the
> field on a vendor 5.4-based ARM32 kernel with the same code path;
> I don't have a setup to reproduce the bogus siTD length on mainline.
I think the bug is rather in the USB contorller code, but it's still
safer to have a sanity check. So I applied now.
thanks,
Takashi
prev parent reply other threads:[~2026-11-10 10:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261110060032epcas1p1a4de057d86d384387d0b8004d63ef331@epcas1p1.samsung.com>
2026-11-10 6:00 ` [PATCH] ALSA: usb-audio: Drop capture packets with bogus actual_length Gichoon Han
2026-11-10 10:46 ` 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=87se19ufoi.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=eadavis@qq.com \
--cc=enscrpt@pm.me \
--cc=gichoon.han@samsung.com \
--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 \
/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.