All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

      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 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.