linux-kernel - Re: [syzbot] memory leak in usb_get

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] [day] [month] [year] [list]

Message-ID: <YizEEq6gib/FNLKr@rowland.harvard.edu>
Date:   Sat, 12 Mar 2022 11:02:26 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Pavel Skripkin <paskripkin@...il.com>
Cc:     syzbot <syzbot+f0fae482604e6d9a87c9@...kaller.appspotmail.com>,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, pavel.hofman@...tera.com,
        rob@...greener.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] memory leak in usb_get_configuration

On Sat, Mar 12, 2022 at 06:45:08PM +0300, Pavel Skripkin wrote:
> > Unfortunately, that won't tell us where the extra reference is coming
> > from.  Here's one thing you could do if you want to continue your
> > debugging: At the start of the probe routines for carl9170, usbtest, and
> > spca501, add code to print in the kernel log the reference count value
> > for the usb_device and usb_interface.  Maybe you'll be able to see where
> > the refcount goes up.
> > 
> 
> Unfortunately refcount for dev and inf stays the same at the beginning of
> each probe function:
> 
> 6 for dev
> 3 for inf

Can you find out how those numbers compare with the values for actual 
working USB devices?

Also, can you see what the device's refcount is just before the 
device_add() call in usb_new_device() and just before the put_device() 
call at the end of usb_disconnect() (both in drivers/usb/core/hub.c)?

If they all are consistent with each then my guess that something is 
failing to drop a reference is probably wrong.

Alan Stern