On Tue, Nov 05, 2024 at 11:02:36AM -0800, Andrew Morton wrote: > On Tue, 5 Nov 2024 11:39:59 -0500 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Mon, Nov 04, 2024 at 08:00:07PM -0800, Andrew Morton wrote: > > > On Wed, 30 Oct 2024 21:54:22 -0700 syzbot <syzbot+ccc0e1cfdb72b664f0d8@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > Hello, > > > > > > > > syzbot found the following issue on: > > > > > > Thanks. I'm suspecting some USB issue - fault injection was used to > > > trigger a memory allocation failure and dec_usb_memory_use_count() ended > > > up freeing an in-use page. Could USB folks please have a look? > > > > Andrew, I'm not sure what to look for. > > Thanks for looking. > > > Can you read through > > usbdev_mmap() in drivers/usb/core/devio.c, along with the four short > > routines preceding it, and let us know if anything seems obviously > > wrong? > > All I see is lots of USB code which I don't understand ;) It seems odd Well, I wouldn't expect you to understand the USB-specific stuff. I was really asking about the memory-management calls and error handling. > that usbdev_mmap() calls dec_usb_memory_use_count() on some error > paths, but goes direct to usbfs_decrease_memory_usage() on others. The paths that call dec_usb_memory_use_count() are those on which a memory buffer has been allocated and needs to be deallocated. That routine then calls usbfs_decrease_memory_usage() as needed. > Did you try running the "C reproducer"? No, I haven't. I haven't had much time to work on this. In fact, I couldn't even tell exactly which call in dec_usb_memory_use_count() caused the fault; the line number listed in the bug report didn't match up with any obvious suspects in my copy of the kernel source. Was it the kfree(usbm) call? Alan Stern
