Re: BUG: bad usercopy in ld_usb_read

[Greg KH <gregkh@linuxfoundation.org>]

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

thanks,

greg k-h