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@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > 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
