Re: [syzbot] [mm?] kernel BUG in __page_table_check_zero (2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 5 Nov 2024 15:42:12 -0500 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:

> 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?

Check out the sysbot commit first: 850925a8133c.  Line 198 is the
hcd_buffer_free_pages() call.

hcd_buffer_free_pages() doesn't appear in the backtrace - a bunch of
things I'd expect to be present aren't there.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux