linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Khazhy Kumykov <khazhy@google.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	syzbot <syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [usb?] KASAN: slab-out-of-bounds Read in read_descriptors (3)
Date: Wed, 26 Jul 2023 06:00:39 +0200	[thread overview]
Message-ID: <2023072648-exclaim-crisply-9d8a@gregkh> (raw)
In-Reply-To: <CACGdZY+qJ7P8FZj6ZGmcDkf2YH7LRBnfvuwiro4ZF37+owHo9g@mail.gmail.com>

On Tue, Jul 25, 2023 at 02:46:37PM -0700, Khazhy Kumykov wrote:
> On Tue, Jul 25, 2023 at 2:30 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Tue, Jul 25, 2023 at 01:42:01PM -0700, Khazhy Kumykov wrote:
> > > On Tue, Jul 25, 2023 at 12:26 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > > > @@ -2671,12 +2671,17 @@ int usb_authorize_device(struct usb_devi
> > > >         }
> > > >
> > > >         if (usb_dev->wusb) {
> > > > -               result = usb_get_device_descriptor(usb_dev, sizeof(usb_dev->descriptor));
> > > > -               if (result < 0) {
> > > > +               struct usb_device_descriptor *descr;
> > > > +
> > > > +               descr = usb_get_device_descriptor(usb_dev);
> > > > +               if (IS_ERR(descr)) {
> > > > +                       result = PTR_ERR(descr);
> > > >                         dev_err(&usb_dev->dev, "can't re-read device descriptor for "
> > > >                                 "authorization: %d\n", result);
> > > >                         goto error_device_descriptor;
> > > >                 }
> > > > +               usb_dev->descriptor = *descr;
> > > Hmm, in your first patch you rejected diffs to the descriptor here,
> > > which might be necessary - since we don't re-initialize the device so
> > > can get a similar issue if the bad usb device decides to change
> > > bNumConfigurations to cause a buffer overrun. (This also stuck out to
> > > me as an exception to the "descriptors should be immutable" comment
> > > later in the patch.
> >
> > I removed that part of the previous patch because there's no point to
> > it.  None of this code ever gets executed; the usb_dev->wusb test can
> > never succeed because the kernel doesn't support wireless USB any more.
> > (I asked Greg KH about that in a separate email thread:
> > <https://lore.kernel.org/linux-usb/2a21cefa-99a7-497c-901f-3ea097361a80@rowland.harvard.edu/#r>.)
> >
> > A later patch will remove all of the wireless USB stuff.  The only real
> > reason for leaving this much of the code there now is to prevent
> > compilation errors and keep the form looking right.
> Ah ok, cool.
> 
> >
> > > > @@ -6018,7 +6064,7 @@ static int usb_reset_and_verify_device(s
> > > >                 /* ep0 maxpacket size may change; let the HCD know about it.
> > > >                  * Other endpoints will be handled by re-enumeration. */
> > > >                 usb_ep0_reinit(udev);
> > > > -               ret = hub_port_init(parent_hub, udev, port1, i);
> > > > +               ret = hub_port_init(parent_hub, udev, port1, i, &descriptor);
> > > Looks like this is the only caller that passes &descriptor, and it
> > > just checks that it didn't change. Would it make sense to put the
> > > enitre descriptors_changed stanza in hub_port_init, for the re-init
> > > case?
> >
> > The descriptors_changed check has to be _somewhere_, either here or
> > there.  I don't see what difference it makes whether the check is done
> > in this routine or in hub_port_init.  Since it doesn't matter, why
> > change the existing code?
> No strong feelings, but it lets us remove the variable in
> usb_reset_and_verify_device() and directly check on the malloc'd copy,
> instead of copying back up to here.
> 
> Overall, looks good to my naive eyes.
> 
> CVE-2023-37453 was filed for this syzbot report, I'm not sure how that
> system gets tracked, but might be good to mention for folks looking
> for a fix.

Who filed CVEs for random syzbot reports?  That's crazy, and no, we
aren't going to track it as CVEs mean nothing for the kernel as I've
said many times.

thanks,

greg k-h

  reply	other threads:[~2023-07-26  4:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20  2:55 [syzbot] [usb?] KASAN: slab-out-of-bounds Read in read_descriptors (3) syzbot
2023-07-21 18:10 ` Khazhy Kumykov
2023-07-21 18:23   ` Khazhy Kumykov
2023-07-21 18:56     ` Alan Stern
2023-07-21 22:40       ` Khazhy Kumykov
2023-07-23  2:01         ` Alan Stern
2023-07-23  2:21           ` syzbot
2023-07-25 19:26             ` Alan Stern
2023-07-25 20:42               ` Khazhy Kumykov
2023-07-25 21:30                 ` Alan Stern
2023-07-25 21:46                   ` Khazhy Kumykov
2023-07-26  4:00                     ` Greg KH [this message]
2023-08-02 20:00                       ` Alan Stern
2023-08-03  6:34                         ` Greg KH
2023-07-25 20:54               ` syzbot

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=2023072648-exclaim-crisply-9d8a@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=khazhy@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.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;
as well as URLs for NNTP newsgroup(s).