All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Maoyi Xie <maoyixie.tju@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: ALSA: caiaq: possible out of bounds read in Traktor Kontrol S4 dispatch
Date: Wed, 17 Jun 2026 14:45:58 +0200	[thread overview]
Message-ID: <87eci5pc6x.wl-tiwai@suse.de> (raw)
In-Reply-To: <178169970022.2950989.3295624331262791202@maoyixie.com>

On Wed, 17 Jun 2026 14:35:00 +0200,
Maoyi Xie wrote:
> 
> Hi all,
> 
> I think the Traktor Kontrol S4 input path in sound/usb/caiaq/input.c can read
> past the end of the URB buffer when the device sends a reply whose length is
> not a multiple of 16. I would appreciate it if you could take a look.
> 
> The dispatch loop walks the reply in fixed 16 byte blocks.
> 
> 	while (len) {
> 		unsigned int i, block_id = (buf[0] << 8) | buf[1];
> 		...
> 		len -= TKS4_MSGBLOCK_SIZE;
> 		buf += TKS4_MSGBLOCK_SIZE;
> 	}
> 
> Each pass reads up to buf[15] and then does len -= 16. But len is the raw
> device length. It comes straight from urb->actual_length in
> snd_usb_caiaq_ep4_reply_dispatch and there is no check that it is a multiple
> of 16. The X1 and Maschine arms in that same handler do bound check the
> length, but the S4 arm does not.
> 
> If len is not a multiple of 16, say 8, the final len -= 16 underflows because
> len is unsigned. The loop condition while (len) then stays true and the walk
> keeps consuming 16 byte blocks far past the end of the buffer. That is an out
> of bounds read. The buffer is cdev->ep4_in_buf of size EP4_BUFSIZE.
> 
> The attacker model is a malicious or emulated USB device that claims the
> Native Instruments Traktor Kontrol S4 id and returns a short reply on its bulk
> in endpoint once the input device is opened.
> 
> I reproduced this under KASAN on 7.1-rc7. A length of one whole block runs the
> loop once and reads nothing past the buffer. A length of 8 underflows and
> KASAN reports a slab out of bounds read just past the allocation.
> 
> The fix I tried is to only consume a block when a whole block is present.
> 
> 	-	while (len) {
> 	+	while (len >= TKS4_MSGBLOCK_SIZE) {
> 
> That stops the decrement from underflowing and drops any trailing partial
> block.
> 
> Does this look like a real bug to you? If the direction is right I am happy to
> send a proper patch with a Fixes tag pointing at 15c5ab607045 ("ALSA:
> snd-usb-caiaq: Add support for Traktor Kontrol S4").

Yes, feel free to submit the patch.

BTW, it seems that there are lots of other places missing the length
check, and we'd need to paper over them, too:
snd_caiaq_input_read_analog(), snd_caiaq_input_read_erp(),
snd_caiaq_input_read_io(), and snd_usb_caiaq_maschine_dispatch().


thanks,

Takashi

  reply	other threads:[~2026-06-17 12:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 12:35 ALSA: caiaq: possible out of bounds read in Traktor Kontrol S4 dispatch Maoyi Xie
2026-06-17 12:45 ` Takashi Iwai [this message]
2026-06-17 13:58   ` Takashi Iwai

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=87eci5pc6x.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=maoyixie.tju@gmail.com \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    --cc=zonque@gmail.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.