From: Felipe Balbi <balbi@kernel.org>
To: "Maciej Żenczykowski" <zenczykowski@gmail.com>,
"Maciej Żenczykowski" <maze@google.com>
Cc: Linux USB Mailing List <linux-usb@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2] usb: fix various gadget panics on 10gbps cabling
Date: Thu, 10 Jun 2021 12:10:07 +0300 [thread overview]
Message-ID: <878s3i2ihc.fsf@kernel.org> (raw)
In-Reply-To: <20210609024459.1126080-1-zenczykowski@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]
Maciej Żenczykowski <zenczykowski@gmail.com> writes:
> From: Maciej Żenczykowski <maze@google.com>
>
> usb_assign_descriptors() is called with 5 parameters,
> the last 4 of which are the usb_descriptor_header for:
> full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),
> high-speed (USB2.0 - 480Mbps),
> super-speed (USB3.0 - 5Gbps),
> super-speed-plus (USB3.1 - 10Gbps).
>
> The differences between full/high/super-speed descriptors are usually
> substantial (due to changes in the maximum usb block size from 64 to 512
> to 1024 bytes and other differences in the specs), while the difference
> between 5 and 10Gbps descriptors may be as little as nothing
> (in many cases the same tuning is simply good enough).
>
> However if a gadget driver calls usb_assign_descriptors() with
> a NULL descriptor for super-speed-plus and is then used on a max 10gbps
> configuration, the kernel will crash with a null pointer dereference,
> when a 10gbps capable device port + cable + host port combination shows up.
> (This wouldn't happen if the gadget max-speed was set to 5gbps, but
> it of course defaults to the maximum, and there's no real reason to
> artificially limit it)
>
> The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,
> if a 10gbps descriptor wasn't provided.
>
> Obviously this won't fix the problem if the 5gbps descriptor is also
> NULL, but such cases can't be so trivially solved (and any such gadgets
> are unlikely to be used with USB3 ports any way).
>
> Cc: Felipe Balbi <balbi@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
nice catch!!
I think this is already in Greg's tree, but in any case:
Acked-by: Felipe Balbi <balbi@kernel.org>
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]
prev parent reply other threads:[~2021-06-10 9:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 4:42 [PATCH] usb: fix various gadget panics on 10gbps cabling Maciej Żenczykowski
2021-06-08 8:54 ` Greg Kroah-Hartman
2021-06-09 2:44 ` [PATCH v2] " Maciej Żenczykowski
2021-06-10 9:10 ` Felipe Balbi [this message]
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=878s3i2ihc.fsf@kernel.org \
--to=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=maze@google.com \
--cc=zenczykowski@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox