All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Subject: Re: Linux USB threat-model document
Date: Wed, 21 Oct 2026 20:26:12 +0200	[thread overview]
Message-ID: <2026102125-guide-slam-e2be@gregkh> (raw)
In-Reply-To: <7480e993-b873-4ea4-ac6e-45bd22975f8a@rowland.harvard.edu>

On Wed, Oct 21, 2026 at 12:53:03PM -0400, Alan Stern wrote:
> On Thu, Feb 26, 2026 at 08:29:45PM -0800, Greg KH wrote:
> > Given that I have to answer this type of question about every other week
> > these days given the fuzzing reports we get sent to the
> > security@kernel.org alias, I think I need to just write up a "here is
> > the Linux USB threat model that we currently support" document to
> > describe what the state is.
> > 
> > We can then work from there, either agreeing that we need to "move" the
> > level of interaction for which we trust / do not trust a device in the
> > lifecycle of a USB device, or just be happy with where it currently is.
> > 
> > That should work better with some groups that I know are working to do
> > stuff to "harden" the USB device stack for some specific use cases,
> > hopefully just using the existing user api that we have today that
> > USBGuard uses, or possibly adding to that to handle some missing areas
> > that we have not previously considered.
> 
> Did you ever make any progress on writing up this document?

No, been swamped by the exponental increase in stable and CVE work :(

> Have these outside groups gotten anywhere, or identified anything that 
> the kernel should do differently?

Yes, there was a presentation at the Plumbers conference in the Android
track about this and what the Android people would like to see be done
differently in order to make this into a more secure type of a system.
The slides for that should be online somewhere and the developers there
said they would be sending patches to the list for review "sometime" in
the future.  Right now I think they have a long way to go before that
happens, but at least they are thinking about it.

thanks,

greg k-h

  reply	other threads:[~2026-10-21 18:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-18  2:13 Stack buffer overflow (write) in kvaser_usb_leaf_wait_cmd via malicious USB Nicholas Carlini
2026-02-18  5:12 ` Greg KH
2026-02-24  8:44   ` Oliver Neukum
2026-02-24 15:52     ` Alan Stern
2026-02-24 16:04       ` Oliver Neukum
2026-02-24 18:43         ` Alan Stern
2026-02-27  4:29           ` Greg KH
2026-02-28  2:22             ` Alan Stern
2026-10-21 16:53             ` Linux USB threat-model document Alan Stern
2026-10-21 18:26               ` Greg KH [this message]
2026-10-22 17:53                 ` Alan Stern

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=2026102125-guide-slam-e2be@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.