From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5517C3F1655 for ; Wed, 17 Jun 2026 12:35:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781699705; cv=none; b=sa/D6czd3Els4EY0Nb5EX5Kf6HzlYev0ehKJAX0BUiWnmzYVTJHPtDuuVlrthYhuOTANY/hyT9D4mMhXCuBlFwqRxK6RV6jpdCsexW3eXMH89s0UVFWVOtC9uc+DVoq66tu8xiNKqJ9fBlzGLFgLmp2X46dDBjZG+gIzNjueHWk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781699705; c=relaxed/simple; bh=TxtAMfRw6c49QPn2ieMmApDAmybdDPBFexqvu7M43FQ=; h=From:To:Cc:Subject:Date:Message-ID:Content-Type:MIME-Version; b=iKvUH3hj3mJaXqUGR4qxznqaRVqsIYKDUZZ+ETVDl5U1FV6RPOVgAapwNl2TaIsC3zDdL7bTs1SSaaxiu4xQDND+360ubXqltwivrI/RaB6jFIM44/ZCqMfCn2Dp5/vTZkTrso0L1BG2VRH6ahSWxQX+m0vsszdVM2Tycaus67c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=F4hM+n98; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F4hM+n98" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2c6bdb8a8bdso4661635ad.1 for ; Wed, 17 Jun 2026 05:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781699704; x=1782304504; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=th+O8xDVpoZexA9d63n8FPaXeCU/tEIdGTSJYT985eA=; b=F4hM+n98rYRYu5c6bgniwaNGxYY7Pt2YrNUPtj+TdJfHeC206g/9U7RR2O7VbjTG+H Laq02OlImRx9tAKTwIXYlDqP4vOBeEIsyOWgmlGMH1Hi/BygTtlAYMnus6nLQ5paHkFB SaJstylkJXRgke+Vck2+M2ht5NnzexGxjHR/qk5p3COBvupliYCERZxpSdmPQPfYLtTD oPKI5OH4Anhe+LkurOYlg1iB7LW3ywHrldGqd3EzBGSaaPCAEt1DI10MHbkzHt+umEN/ ChIGednZyK1XBi705BcoH+okbbna8Q6YcRX9HpU4Xik81fylpW2TFqLHhhAazS/Jy1a5 SXTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781699704; x=1782304504; h=mime-version:content-transfer-encoding:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=th+O8xDVpoZexA9d63n8FPaXeCU/tEIdGTSJYT985eA=; b=DFoJLzdILlkEEZ3z5V31BWMRt4WJ7NTJpBdXt3bnCURN7qdcEoXDL2axZ26kvbEKnq Hf4KSwkXAxEiHKYPjnb4SIV2JHu/mThABC5xQRC7ihvc8Lr9uPlBJEDxPb46LIcw+g+i tUEsk34s0XsxsLrcrObbRnNXK7iF82dERzoURHAlR9rBMeWgOyjqCjvUM0qQMMehi5ov y2Yo8GxiUgoi0PNg8YkaEyIC5xntE8G6s9okY/o1TU8RfnPU6tMjSR9kKJIBl8VKmsLt tAfaMn8naiyKlXSen7KQGmuT3nyLiR0MAiMcgIs8SJEzRdlHIaYPEjJG9oAx4pq2h688 tgBg== X-Forwarded-Encrypted: i=1; AFNElJ+WdUzED75A+WkPEKtfuJG6Bmd17h1D98Prsg2De1gOjlub94BoCOoWLg9ssmN2eKJMYBE4pt/8EVuX37Q=@vger.kernel.org X-Gm-Message-State: AOJu0YxCT/buRjL83ddzOea9W17En8L4wuEMd8Zjjl8KxdlUM/vdGtA1 1020GwIhH6TIgj8GfibjSKo8QOaAKJsrtGVIyUH3WGd6lrY+8r7YCtn0FMXJMA== X-Gm-Gg: AfdE7ckiVigVWvfr/P0WAjPVQglDWUvy54tLugWXQITiXpxfF9nth8hNAoNieXGb4E2 oYDYS/RcfmaXkxzG2d3jIBIn/HcsIAdJKFjIaJYElZstevWxriRwKa7UdtKckWY3Bnn1PfKfRo1 vfUsIvuwFMLwfHOZnKGj9AJhKDROy1WA7qENORVsE6hzF7tpdqe4zZM6b8TVf98JqJHM5DaQR1U 5aRHhqRsgUMLgDkjHgKGj3xWTZq6NEUErQC5OTmxxtSEI+bGsElo8gB64n3vq5UgTy+4kqATL3b dPA4fNeRtxlrmNYcGAMaKxAvHWYNBC7musfRLw1JYD/gVNjPRKM9fwh2IrQvaUs0LMLj+EpscYA MBWMnoD9FeA2ZuFaGpZFux9QyQ8QjvyLwN0+7L0sxRKN7X+Pej9cSbzVc2aP3itclQhFdVGsQSA WFcwwWzdrTymUJ1cZOK4PQP18+s/nLsZe076wboQ== X-Received: by 2002:a17:903:13c7:b0:2c6:abaf:85fb with SMTP id d9443c01a7336-2c6bc26b754mr35379215ad.32.1781699703518; Wed, 17 Jun 2026 05:35:03 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c6be262b93sm21980295ad.68.2026.06.17.05.35.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 05:35:02 -0700 (PDT) From: Maoyi Xie To: Daniel Mack , Jaroslav Kysela , Takashi Iwai Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: ALSA: caiaq: possible out of bounds read in Traktor Kontrol S4 dispatch Date: Wed, 17 Jun 2026 20:35:00 +0800 Message-ID: <178169970022.2950989.3295624331262791202@maoyixie.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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"). Thanks, Maoyi https://maoyixie.com/