From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 45F7A36165E for ; Thu, 23 Apr 2026 22:28:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776983328; cv=none; b=fGvaEYTz4vchmDhVJagCeu06eXI/vcvS5QsacQOW2JaxHhe9rNHTM8+09nId9hLyNc6B7z6FSievfyc5Z4LhlgRR34X7pJQAxSz8VLsnfxzGpJn838j0Y40mm20wZcQFXO5jXpJ3O0bM1t/SzPwddQfom1/BoCeV90Wo4GcyFNs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776983328; c=relaxed/simple; bh=l67yrJ/UZzx+pXWqRiRNcT9T9iO6K+b2juS+2KALSQw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qQgSUHjvpw7pCxGR6NadbmZ/Bn7pE3lteP5pGYMpQcBdr8oGLMyxVd06ehHoZGf+Qz/6gYOBdhcnRJcQMlRg70QHLLpOgWrUcVCTRRafhvCZ+/+NCdAb1atScR47bWMVvmRIulLv/a8JN9m6MTuG+84XO2HKtp3rqnXJO+wsczc= 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=SrhjClDl; arc=none smtp.client-ip=209.85.208.173 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="SrhjClDl" Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-38e12c67a6fso71920671fa.1 for ; Thu, 23 Apr 2026 15:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776983325; x=1777588125; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YfoWb8W4UVEmeLvxChwZ84X+xyL4SxpAJaIS+MUYhoc=; b=SrhjClDlVnWQpXl0T4trYyeSAJjn0D2Dj24vydeOMnn1S6HsgkJA+DmBvvV6YeUkPJ ovNIRMEFoCdJ3VHWPjoRvgu5hIkrI7SfNxOuasjxOuK60xbjGc02lVtt5cv+TlDwkRm7 kCLRcTNdJ3CAuwGXEDAhtGXxqkH5mq38oFWcQP8y724khtyasLrnkfI+0woWKL6Edi5f kdM8JCurRZnUsN/W7XQZ+MglBpeG8EhfPBH5rQbgCDKNZVcdVtTWgN1xM0gfIBg8CUIu qZLYWKxRkPZwpvC6oqdiEHJXLgoBxMH0bCumgICDlK6BUeGPwXQWbl1R2S55OEO8VqHo KUfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776983325; x=1777588125; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=YfoWb8W4UVEmeLvxChwZ84X+xyL4SxpAJaIS+MUYhoc=; b=dXlyTFaPCON7PrVbUY43ri8QBLCh8p0dZDbYAJPurAIoiuIC8eeWAmZCi60zaJ7fvD /WrckxReL5t43uIbQi7j+XgrVZrPFZY8fX+aVN5kfTTqlBh4buPfRf2u7WvcJkD4tCWD KdPq3KYVN7r5y/DLIEGkb0SMgLCo7Yk1HARU+iP0keXUerTDDEb/TJtbwq4xg8ml8rbG sy34LMAxRa42jbXHAwa1qp6ywliCiPzOyZzNa7Atm0jkQQMV9DjB+cuTS//ZUhygPXVW SiGui4mDNzbg53W+AyIGylKEvBxPIl98/3HygZXlEt7SYjDGKbuvRO8YTMqDA2KltXUb By9Q== X-Forwarded-Encrypted: i=1; AFNElJ8eOx4l/MPSAgxC163fWVoAnALDoSXJ4ja6+qiWhNPBN9O0ZmQh4IqN1rqkCjiwS/J0rEoVAnMgWzQaM7A=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1ynfzz7La5lPyB160oUqLxhxsbyFtuRBc00s3O+U/lG8TgNih AXtrekcd4FlPcJcNedUcdY81ZxsBE2Ae7MceNVV0NUvaeBCLch4CR5KZ X-Gm-Gg: AeBDieuhdrS4fs7IIGC1gEu1crz8Tc6eq5GijIcQcAZ1EUMH/E2f8CUldG8QQenJWpU 34UYv8+tbvqzuo+7Ul6Ab2iurGowOTFArBopsIrZtdA3iJwDaYWCqo32xQ7bIEmfbJ3e7U3PMZn 0mW+pM5ANmmZBx7OXTfM7emEiPMNOwYjXQnw3oIxsqaosxSkVMUYprafgyI8EsDc8HUKmNEsmhZ vv7Y+YHM1qXoxLDvLRiBMUya71RDb1ZiCnTdJLdi62iEgXeYeeF1SVU1KX9ABD5jIir/5XhgrH3 SE8zXsY1XPyfZc6UIjcFC9lFBsu3Eryx3GZxOZ1Xr7T6MTGQcypHMrrWCamXp8a+kEW39l7Dtyw u9hsb61hZ2nBFLYJ6yS7J02g3F8QtD+xX9dLS6nwpzpHNKof/zjp+Hf+DpMLFdox0ie20ypuXEU zes//UupXaIYrPdCKLqOOtanwNfj/K/6mp8520Uw3g0r4= X-Received: by 2002:a2e:9a0e:0:b0:38f:20cc:2bb0 with SMTP id 38308e7fff4ca-38f20cc3732mr67753571fa.23.1776983325138; Thu, 23 Apr 2026 15:28:45 -0700 (PDT) Received: from foxbook (bfh75.neoplus.adsl.tpnet.pl. [83.28.45.75]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-38ecb4f5119sm41915471fa.2.2026.04.23.15.28.42 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 23 Apr 2026 15:28:44 -0700 (PDT) Date: Fri, 24 Apr 2026 00:28:39 +0200 From: Michal Pecio To: Heitor Alves de Siqueira Cc: Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-dev@igalia.com, syzbot+abbfd103085885cf16a2@syzkaller.appspotmail.com, stable@kernel.org Subject: Re: [PATCH v2] usb: usbtmc: reject invalid interrupt endpoints Message-ID: <20260424002839.5ad25517.michal.pecio@gmail.com> In-Reply-To: <20260423-usbtmc-iin-size-v2-1-31afa4874f71@igalia.com> References: <20260423-usbtmc-iin-size-v2-1-31afa4874f71@igalia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 23 Apr 2026 15:04:38 -0300, Heitor Alves de Siqueira wrote: > The USBTMC driver allocates the Interrupt-IN buffer according to the > wMaxPacketSize value obtained from the USB endpoint. If a USB device > advertises a small enough wMaxPacketSize (e.g. a malfunctioning device > or an endpoint constructed by syzbot), the buffer will not have enough > space for the mandatory headers and will trigger an out-of-bounds read. > > Fix by rejecting devices advertising interrupt endpoints that don't fit > at least the mandatory headers (bNotify1 and bNotify2). > > Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.") > Reported-by: syzbot+abbfd103085885cf16a2@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=abbfd103085885cf16a2 > Cc: stable@kernel.org > Suggested-by: Michal Pecio > Signed-off-by: Heitor Alves de Siqueira > --- > Changes in v2: > - Instead of ensuring buffer size, reject devices that advertise illegal/invalid interrupt endpoints > - Link to v1: https://patch.msgid.link/20260422-usbtmc-iin-size-v1-1-5dc44b4389aa@igalia.com On second thought, this may be not enough. A wMaxPacketSize == 2 device can still send only 1 byte (or even 0) and cause unititialized read. Better check if the URB completed with expected actual_length before trying to parse the message. And by the way, an interrupt transfer may span multiple intervals and exceed wMaxPacketSize, USBTMC spec alludes to it. Theoretically, even wMaxPacketSize == 1 seems possible, though it would be crazy and likely no such HW exists because nobody complains that it doesn't work. Regards, Michal