From: "Heitor Alves de Siqueira" <halves@igalia.com>
To: "Michal Pecio" <michal.pecio@gmail.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
<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
Date: Thu, 30 Apr 2026 15:31:55 -0300 [thread overview]
Message-ID: <DI6PD3MOZAXW.RNUBKGQG1O6M@igalia.com> (raw)
In-Reply-To: <20260429001626.2f08b991.michal.pecio@gmail.com>
On Tue Apr 28, 2026 at 7:16 PM -03, Michal Pecio wrote:
> I'm completely unfamiliar with this class, but my understanding of
> USBTMC spec is that bNotify1 is mandatory while bNotify2 may have
> any length, likely including zero, though it's a bit imprecise.
>
> The driver only supports notifications defined in the separate USB488
> spec and for these, bNotify2 should be one byte. It also warns on
> every unrecognized notification.
>
> I think a minimal fix which mostly preserves existing behavior would
> be adding "urb->actual_length == 2" as a requirement for all USB488
> notifications. Then any truncated message will be ignored and logged.
Yes, that's my understanding as well! Although I don't think bNotify2
would ever be zero in practice, this sounds like a good approach. I'll
submit a v3 with this change plus the endpoint check from v2, hopefully
that'll improve things for these edge cases.
> wMaxPacketSize is a separate issue indeed and it seems that a USB488
> device could legally set it to 1, though it would be crazy. Your v1
> patch would probably make such devices work, if anyone cares.
Honestly, I'm also more inclined to just reject endpoints with this
configuration. This seems like a very niche edge-case, I'd be surprised
if real hardware operated like this (famous last words? heh). I'm not
sure if this would even be valid/legal, given your previous point on
bNotify2 being one byte. Considering these devices do not work at all
currently, checking if wMaxPacketSize and urb->actual_length are big
enough seems like a saner approach and won't require bigger changes to
the driver.
Thanks for the help, Michal!
Best regards,
Heitor
next prev parent reply other threads:[~2026-04-30 18:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 18:04 [PATCH v2] usb: usbtmc: reject invalid interrupt endpoints Heitor Alves de Siqueira
2026-04-23 22:28 ` Michal Pecio
2026-04-28 19:55 ` Heitor Alves de Siqueira
2026-04-28 22:16 ` Michal Pecio
2026-04-30 18:31 ` Heitor Alves de Siqueira [this message]
2026-04-30 20:48 ` Michal Pecio
2026-04-30 21:04 ` Michal Pecio
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=DI6PD3MOZAXW.RNUBKGQG1O6M@igalia.com \
--to=halves@igalia.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michal.pecio@gmail.com \
--cc=stable@kernel.org \
--cc=syzbot+abbfd103085885cf16a2@syzkaller.appspotmail.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.