From: John Keeping <john@metanate.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Lee Jones <lee@kernel.org>, Greg KH <gregkh@linuxfoundation.org>,
balbi@kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/1] usb: gadget: f_hid: Conduct proper refcounting on shared f_hidg pointer
Date: Mon, 21 Nov 2022 12:38:37 +0000 [thread overview]
Message-ID: <Y3txTcASyvTWqFlc@donbot> (raw)
In-Reply-To: <Y3qSImZkZwCG1kA1@rowland.harvard.edu>
On Sun, Nov 20, 2022 at 03:46:26PM -0500, Alan Stern wrote:
> On Sun, Nov 20, 2022 at 05:22:19PM +0000, John Keeping wrote:
> > On Fri, Nov 18, 2022 at 04:07:24PM -0500, Alan Stern wrote:
> > > 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?
> >
> > The problem is that we have a struct cdev embedded in f_hidg but the
> > lifetime of f_hidg is not tied to any kobject so we can't solve this in
> > the right way by setting the parent kobject of the cdev.
> >
> > While refcounting struct f_hidg is necessary, it's not sufficient
> > because the only way to keep it alive long enough for the final
> > kobject_put() on the embedded cdev is to tie the lifetime to a kobject
> > of its own and there is no suitable object as this is not the model
> > followed by gadget function instances.
>
> I see. The solution is simple: Embed a struct device in struct f_hidg,
> and call cdev_device_add() to add the device and the cdev. This will
> automatically make the device the parent of the cdev, so the device's
> refcount won't go to 0 until the cdev's refcount does. Then you can tie
> the f_hidg's lifetime to the device's, so the device's release routine
> can safely deallocate the entire f_hidg structure.
>
> The parent of the new struct device should be set to &gadget->dev. If
> you can't think of a better name for the device, you could simply append
> ":I" to the parent's name, where I is the interface number, or even
> append ":C.I" where C is the config number (like we do on the host
> side).
There is no gadget->dev at the time struct f_hidg is allocated.
AFAICT the device is the UDC, which is only associated with the gadget
when it is bound. The functions are allocated earlier than this and I
can't see any device associated with struct usb_function_instance.
The patch below does fix the issue, but I'm wondering if there's a
deeper problem here that can only be properly solved by adding some
device/kobject hierarchy to the config side of things.
-- >8 --
Subject: [PATCH] usb: gadget: f_hid: fix f_hidg lifetime vs cdev
The embedded struct cdev does not have its lifetime correctly tied to
the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN
is held open while the gadget is deleted.
This can readily be replicated with libusbgx's example programs (for
conciseness - operating directly via configfs is equivalent):
gadget-hid
exec 3<> /dev/hidg0
gadget-vid-pid-remove
exec 3<&-
Add a device to f_hidg so that the cdev can properly take a reference to
this and the structure will be freed only when the child device is
released.
[Also fix refcount leak on an error path.]
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/usb/gadget/function/f_hid.c | 35 ++++++++++++++++++++++++-----
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_hid.c b/drivers/usb/gadget/function/f_hid.c
index ca0a7d9eaa34..7ae97e5c4d20 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -71,6 +71,7 @@ struct f_hidg {
wait_queue_head_t write_queue;
struct usb_request *req;
+ struct device dev;
int minor;
struct cdev cdev;
struct usb_function func;
@@ -84,6 +85,14 @@ static inline struct f_hidg *func_to_hidg(struct usb_function *f)
return container_of(f, struct f_hidg, func);
}
+static void hidg_release(struct device *dev)
+{
+ struct f_hidg *hidg = container_of(dev, struct f_hidg, dev);
+
+ kfree(hidg->set_report_buf);
+ kfree(hidg);
+}
+
/*-------------------------------------------------------------------------*/
/* Static descriptors */
@@ -999,6 +1008,7 @@ static int hidg_bind(struct usb_configuration *c, struct usb_function *f)
/* create char device */
cdev_init(&hidg->cdev, &f_hidg_fops);
+ cdev_set_parent(&hidg->cdev, &hidg->dev.kobj);
dev = MKDEV(major, hidg->minor);
status = cdev_add(&hidg->cdev, dev, 1);
if (status)
@@ -1244,9 +1254,7 @@ static void hidg_free(struct usb_function *f)
hidg = func_to_hidg(f);
opts = container_of(f->fi, struct f_hid_opts, func_inst);
- kfree(hidg->report_desc);
- kfree(hidg->set_report_buf);
- kfree(hidg);
+ device_unregister(&hidg->dev);
mutex_lock(&opts->lock);
--opts->refcnt;
mutex_unlock(&opts->lock);
@@ -1266,6 +1274,7 @@ static struct usb_function *hidg_alloc(struct usb_function_instance *fi)
{
struct f_hidg *hidg;
struct f_hid_opts *opts;
+ int ret;
/* allocate and initialize one new instance */
hidg = kzalloc(sizeof(*hidg), GFP_KERNEL);
@@ -1277,17 +1286,27 @@ static struct usb_function *hidg_alloc(struct usb_function_instance *fi)
mutex_lock(&opts->lock);
++opts->refcnt;
+ device_initialize(&hidg->dev);
+ hidg->dev.release = hidg_release;
+ ret = dev_set_name(&hidg->dev, "hidg%d", hidg->minor);
+ if (ret) {
+ --opts->refcnt;
+ mutex_unlock(&opts->lock);
+ return ERR_PTR(ret);
+ }
+
hidg->minor = opts->minor;
hidg->bInterfaceSubClass = opts->subclass;
hidg->bInterfaceProtocol = opts->protocol;
hidg->report_length = opts->report_length;
hidg->report_desc_length = opts->report_desc_length;
if (opts->report_desc) {
- hidg->report_desc = kmemdup(opts->report_desc,
+ hidg->report_desc = devm_kmemdup(&hidg->dev, opts->report_desc,
opts->report_desc_length,
GFP_KERNEL);
if (!hidg->report_desc) {
- kfree(hidg);
+ put_device(&hidg->dev);
+ --opts->refcnt;
mutex_unlock(&opts->lock);
return ERR_PTR(-ENOMEM);
}
@@ -1307,6 +1326,12 @@ static struct usb_function *hidg_alloc(struct usb_function_instance *fi)
/* this could be made configurable at some point */
hidg->qlen = 4;
+ ret = device_add(&hidg->dev);
+ if (ret) {
+ put_device(&hidg->dev);
+ return ERR_PTR(ret);
+ }
+
return &hidg->func;
}
--
2.38.1
next prev parent reply other threads:[~2022-11-21 12:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 12:08 [PATCH 1/1] usb: gadget: f_hid: Conduct proper refcounting on shared f_hidg pointer Lee Jones
2022-11-17 12:50 ` Greg KH
2022-11-17 13:26 ` Lee Jones
2022-11-17 17:38 ` Greg KH
2022-11-17 12:50 ` Greg KH
2022-11-17 13:46 ` Lee Jones
2022-11-17 16:47 ` Alan Stern
2022-11-18 8:54 ` Lee Jones
2022-11-18 15:59 ` Alan Stern
2022-11-18 16:37 ` John Keeping
2022-11-18 21:07 ` Alan Stern
2022-11-20 17:22 ` John Keeping
2022-11-20 20:46 ` Alan Stern
2022-11-21 12:30 ` Lee Jones
2022-11-21 12:38 ` John Keeping [this message]
2022-11-21 16:18 ` Alan Stern
2022-11-21 18:54 ` John Keeping
2022-11-21 19:17 ` Alan Stern
2022-11-22 11:52 ` John Keeping
2022-11-22 8:31 ` Lee Jones
2022-11-22 11:55 ` John Keeping
-- strict thread matches above, loose matches on Subject: below --
2022-10-17 11:27 Lee Jones
2022-10-22 12:52 ` Greg Kroah-Hartman
2022-10-24 7:17 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y3txTcASyvTWqFlc@donbot \
--to=john@metanate.com \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.