mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Sinan Turunc <enscrpt@pm.me>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] ALSA: usx2y: Reject buffers smaller than two packets
Date: Wed, 04 Nov 2026 08:34:19 +0100	[thread overview]
Message-ID: <87h5hxuk1w.wl-tiwai@suse.de> (raw)
In-Reply-To: <87se1hukq1.wl-tiwai@suse.de>

On Wed, 04 Nov 2026 08:19:50 +0100,
Takashi Iwai wrote:
> 
> On Tue, 03 Nov 2026 14:23:03 +0100,
> Sinan Turunc wrote:
> > 
> > usx2y_urb_capt_retire() splits the copy into the ALSA ring buffer once
> > at the buffer end and wraps hwptr_done once, which is only correct when
> > one packet holds at most buffer_size frames. The packet size is the
> > endpoint's maxpacksize from usb_maxpacket(), while the hw constraints
> > allow 64-byte periods with periods_min 2, so a packet can be larger than
> > the whole buffer.
> > 
> > The endpoint is known at probe time, so constrain
> > SNDRV_PCM_HW_PARAM_BUFFER_BYTES in snd_usx2y_pcm_open() to at least
> > twice the endpoint's packet size. Two packets, matching the line6 fix.
> > The bound makes the copy safe, but it does not make every larger buffer
> > progress: the position is reported once per URB of 4 packets, so a
> > buffer that divides one URB's data returns to the same position at every
> > callback. That was already the case before this patch and is not changed
> > here. Keep a guard in usx2y_urb_capt_retire() that drops an oversized
> > packet with a ratelimited error, for the case that should no longer be
> > reachable.
> > 
> > Reproduced on 7.3-rc7 with a USB/IP device presenting the US-122
> > interface layout and 1024-byte packets into a 512-byte buffer:
> > 
> >   BUG: KASAN: out-of-bounds in i_usx2y_urb_complete+0x1285/0x1ac0
> >   Read of size 18446744073709551104 at addr ffff88800e448800 by task vhci_rx/83
> > 
> > With this patch a 1024-byte buffer is refused at hw_params; a 2048-byte
> > buffer is accepted and safe but barely advances (hw_ptr 9216 after 30 s,
> > for the reason above); a 3072-byte buffer streams for 30 s with no
> > report and with the position moving inside the buffer.
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Sinan Turunc <enscrpt@pm.me>
> 
> Applied now.  thanks.

... and I noticed Sashiko warnings now, so dropped again from the
queue.  Could you verify whether those complaints are valid or not?


thanks,

Takashi

  reply	other threads:[~2026-11-04  7:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 13:23 Sinan Turunc
2026-11-04  7:19 ` Takashi Iwai
2026-11-04  7:34   ` Takashi Iwai [this message]
2026-11-04 10:52     ` Sinan Turunc

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=87h5hxuk1w.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=enscrpt@pm.me \
    --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 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®