linux-kernel - Re: BUG: bad usercopy in ld_usb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1908091100580.1630-100000@iolanthe.rowland.org>
Date:   Fri, 9 Aug 2019 11:13:00 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Greg KH <gregkh@...uxfoundation.org>
cc:     Kees Cook <keescook@...omium.org>,
        syzbot <syzbot+45b2f40f0778cfa7634e@...kaller.appspotmail.com>,
        Michael Hund <mhund@...didactic.de>,
        <akpm@...ux-foundation.org>, <andreyknvl@...gle.com>, <cai@....pw>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        <linux-usb@...r.kernel.org>, <syzkaller-bugs@...glegroups.com>,
        <tglx@...utronix.de>
Subject: Re: BUG: bad usercopy in ld_usb_read

On Fri, 9 Aug 2019, Greg KH wrote:

> On Thu, Aug 08, 2019 at 04:06:32PM -0700, Kees Cook wrote:
> > On Thu, Aug 08, 2019 at 02:46:54PM +0200, Greg KH wrote:
> > > On Thu, Aug 08, 2019 at 05:38:06AM -0700, syzbot wrote:
> > > > Hello,
> > > > 
> > > > syzbot found the following crash on:
> > > > 
> > > > HEAD commit:    e96407b4 usb-fuzzer: main usb gadget fuzzer driver
> > > > git tree:       https://github.com/google/kasan.git usb-fuzzer
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=13aeaece600000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=45b2f40f0778cfa7634e
> > > > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > > > 
> > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > 
> > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > Reported-by: syzbot+45b2f40f0778cfa7634e@...kaller.appspotmail.com
> > > > 
> > > > ldusb 6-1:0.124: Read buffer overflow, -131383996186150 bytes dropped
> > > 
> > > That's a funny number :)
> > > 
> > > Nice overflow found, I see you are now starting to fuzz the char device
> > > nodes of usb drivers...
> > > 
> > > Michael, care to fix this up?
> > 
> > This looks like the length in the read-from-device buffer is unchecked:
> > 
> >         /* actual_buffer contains actual_length + interrupt_in_buffer */
> >         actual_buffer = (size_t *)(dev->ring_buffer + dev->ring_tail * (sizeof(size_t)+dev->interrupt_in_endpoint_size));
> >         bytes_to_read = min(count, *actual_buffer);
> >         if (bytes_to_read < *actual_buffer)
> >                 dev_warn(&dev->intf->dev, "Read buffer overflow, %zd bytes dropped\n",
> >                          *actual_buffer-bytes_to_read);
> > 
> >         /* copy one interrupt_in_buffer from ring_buffer into userspace */
> >         if (copy_to_user(buffer, actual_buffer+1, bytes_to_read)) {
> >                 retval = -EFAULT;
> >                 goto unlock_exit;
> >         }
> > 
> > I assume what's stored at actual_buffer is bogus and needs validation
> > somewhere before it's actually used. (If not here, maybe where ever the
> > write into the buffer originally happens?)
> 
> I think it should be verified here, as that's when it is parsed.  The
> data is written to the buffer in ld_usb_interrupt_in_callback() but it
> does not "know" how to parse it at that location.

I looked at this bug report, and it is very puzzling.

Yes, the value stored in *actual_buffer is written in
ld_usb_interrupt_in_callback(), but the value is simply
urb->actual_length and therefore does not need any validation.  The 
URB's transfer_buffer_length is taken from 
dev->interrupt_in_endpoint_size, which comes from usb_endpoint_maxp() 
and therefore cannot be larger than 2048.

(On the other hand, actual_buffer might not be aligned on a 32-bit 
address.  For x86, of course, this doesn't matter, but it can affect 
other architectures.)

Furthermore, the computation leading to the dev_warn() involves only
size_t types and therefore is carried out entirely using unsigned
arithmetic.  The warning's format string uses %zd instead of %zu;  
that's why the number showed up as negative but doesn't explain why it
looks so funny.

In fact, I don't see why any of the computations here should overflow
or wrap around, or even give rise to a negative value.  If syzbot had a
reproducer we could get more debugging output -- but it doesn't.

Alan Stern