linux-kernel - Re: [PATCH 1/1] usb: gadget: f_hid: Conduct proper refcounting on shared f

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

Message-ID: <Y3f0DJTOQ/8TVX0h@rowland.harvard.edu>
Date:   Fri, 18 Nov 2022 16:07:24 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     John Keeping <john@...anate.com>
Cc:     Lee Jones <lee@...nel.org>, Greg KH <gregkh@...uxfoundation.org>,
        balbi@...nel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org
Subject: Re: [PATCH 1/1] usb: gadget: f_hid: Conduct proper refcounting on
 shared f_hidg pointer

On Fri, Nov 18, 2022 at 04:37:32PM +0000, John Keeping wrote:
> I don't think it's at all simple to fix this - I posted a series
> addressing the lifetime issues here a few years ago but didn't chase it
> up and there was no feedback:
> 
> 	https://lore.kernel.org/linux-usb/20191028114228.3679219-1-john@metanate.com/
> 
> That includes a patch to remove the embedded struct cdev and manage its
> lifetime separately, which I think is needed as there are two different
> struct device objects here and we cannot tie their lifetimes together.

I still don't have a clear picture of what the real problem is.  Lee's 
original patch description just said "external references are presently 
not tracked", with no details about what those external references are. 
Why not add just proper cdev_get() and cdev_put() calls to whatever code 
handles those external references, so that they _are_ tracked?

What are the two different struct device objects?  Why do their 
lifetimes need to be tied together?  If you do need to tie their 
lifetimes somehow, why not simply make one of them (the one which is 
logically allowed to be shorter-lived) hold a reference to the other?

Alan Stern