public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Oliver Neukum <oneukum@suse.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: Hardening the parser during enumerations
Date: Fri, 12 Apr 2024 09:54:23 +0200	[thread overview]
Message-ID: <2024041251-gratitude-open-c48c@gregkh> (raw)
In-Reply-To: <45c446c7-bd69-4202-8de4-d3305fe83cda@suse.com>

On Thu, Apr 11, 2024 at 05:37:13PM +0200, Oliver Neukum wrote:
> On 11.04.24 16:09, Greg KH wrote:
> 
> > Right now, we barely trust USB descriptors, if we wish to change this
> > threat-model, that's great, but I think a lot of work is still to be
> > done as you prove here.
> 
> Indeed. As this is fiddly and holes are easy to overlook,
> anything I've missed?

We have had loads of fuzzing on the basic "parse the descriptors" logic,
so that's looking much better than before.  If you have actual
test-cases for the series you have here, that would help as well (we
need to integrate the syzbot usb descriptor fuzzing logic into kselftest
one of these days) so that both you can test if the changes are needed
(as Alan is pointing out they might not be), and that we can ensure that
future changes do not break anything.

But once a driver takes over for the device, all bets are off, we are
just now possibly hope that the endpoint assignment logic in drivers are
correct (so any help there is always appreciated), but after that, the
size of the endpoints and other basic protocol handling is fully
"trusted" and odds are no error checking is happening anywhere in almost
any driver.

So that means you still can not treat USB devices as "untrusted" sorry.
Just like any other hardware device in Linux.  So the threat-model is
the same, we have to trust the hardware.

thanks,

greg k-h

      reply	other threads:[~2024-04-12  7:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11 12:42 Hardening the parser during enumerations Oliver Neukum
2024-04-11 12:42 ` [RFC 1/6] usb: usb_parse_endpoint ignore reserved bits Oliver Neukum
2024-04-11 14:11   ` Greg KH
2024-04-11 14:27     ` Oliver Neukum
2024-04-11 14:58       ` Greg KH
2024-04-11 15:35   ` Alan Stern
2024-04-11 15:40     ` Oliver Neukum
2024-04-11 12:43 ` [RFC 2/6] usb: avoid overrunning a buffer in usb_parse_interface Oliver Neukum
2024-04-11 15:39   ` Alan Stern
2024-04-11 17:36     ` Alan Stern
2024-04-11 12:43 ` [RFC 3/6] usb: usb_parse_endpoint needs to guard against short descriptors Oliver Neukum
2024-04-11 15:57   ` Alan Stern
2024-04-11 12:43 ` [RFC 4/6] usb: usb_parse_endpoint guard against an incromprehensible preamble Oliver Neukum
2024-04-11 16:00   ` Alan Stern
2024-04-11 12:43 ` [RFC 5/6] usb: usb_parse_endpoint must not count duplicated endpoints Oliver Neukum
2024-04-11 16:04   ` Alan Stern
2024-04-11 12:43 ` [RFC 6/6] usb: config: find_next_descriptor can overflow buffer Oliver Neukum
2024-04-11 16:16   ` Alan Stern
2024-04-11 14:09 ` Hardening the parser during enumerations Greg KH
2024-04-11 15:37   ` Oliver Neukum
2024-04-12  7:54     ` Greg KH [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=2024041251-gratitude-open-c48c@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oneukum@suse.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