Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4821313rwb; Mon, 21 Nov 2022 12:22:31 -0800 (PST) X-Google-Smtp-Source: AA0mqf6WnL7XwQezejkuo4Bfa9JlwbsWv0EKr/5/tmhbopNKeU+7B21773COwqem4VEj46X5rxmo X-Received: by 2002:aa7:8115:0:b0:571:f667:4d85 with SMTP id b21-20020aa78115000000b00571f6674d85mr4344157pfi.70.1669062151647; Mon, 21 Nov 2022 12:22:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669062151; cv=none; d=google.com; s=arc-20160816; b=Rdi6XlJRIURLaxJkJE/1zccB5ibRP5+ns9vlICJBTWOUxP62RrUP3mD0bjBnFabr41 SPO3QZc91J2YkPFnChW1Y6KtfOJVWPB5yHCdOznE4+5mUA23lKeZ0kiRg2kV/96Cx/s/ dUwCbuQQxuIFpwY5cbdMuHboIUgPQwfTZP4n4trzPSd/CyVwWkYm84dCazvbN/jYlXm2 xfTMhx5s6ESmwRerQOor/Bwh51K3pUNW9ZH+umLqlZmsWEdGi7Cj6KrYVwbDmIAOJE1D syoHDCwdqZVGxrzNvmqpS1Hal1tY1sPYuWqhKwEy/f259WVpVHNjs9U/2O6voWNhy7yR 3TiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=/Y/i7fnsc/O1BadU8YAaf1qYYXi2/0uF3REhKocLZBM=; b=hAYBC+dTwp0/QNRWbLManz3br/IK4BlWkruxVS/oiDZXHLZH6jnvQnitvlG3OouHqh nFkTORnbU7Y7gwmlbd+qnzqa/+p/tMvqvaSFRMEmxudw/Mp3hXkpveRKMoWnBooVUZx4 OBltE7eXhd02zeL38o9ZCxoL423tiqTsd+ly/fSSMElq0DWxyTXCk27G0cVynOPmAdGb IuNpDiN5CF64fhrxHUiJx11HDZzU+HwQdi3xHMcLJAmQk41gHQk4uE2sq6ZAk/8LNnlR /99s7coDY7vj0kb2g4EyX7u7netcNIDBVfnGK1Z3uXQNrvdxpiixRaY4yy2yLq/7CjRp htXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g18-20020a056a001a1200b0052c56cea553si13381144pfv.352.2022.11.21.12.22.19; Mon, 21 Nov 2022 12:22:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229908AbiKUTSp (ORCPT + 91 others); Mon, 21 Nov 2022 14:18:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231302AbiKUTSX (ORCPT ); Mon, 21 Nov 2022 14:18:23 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 0CA5BDA4F3 for ; Mon, 21 Nov 2022 11:17:58 -0800 (PST) Received: (qmail 128144 invoked by uid 1000); 21 Nov 2022 14:17:56 -0500 Date: Mon, 21 Nov 2022 14:17:56 -0500 From: Alan Stern To: John Keeping Cc: Lee Jones , Greg KH , 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 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 21, 2022 at 06:54:55PM +0000, John Keeping wrote: > It turns out there's already a device being created here, just not > associated with the structure. Your suggestions around > cdev_device_add() made me spot what's going on with that so the actual > fix is to pull its lifetime up to match struct f_hidg. It's not obvious from the patch what device was already being created, but never mind... > -- >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<&- > > Pull the existing device up in to struct f_hidg and make use of the > cdev_device_{add,del}() helpers. This changes the lifetime of the > device object to match struct f_hidg, but note that it is still added > and deleted at the same time. > > [Also fix refcount leak on an error path.] > > Signed-off-by: John Keeping > --- > drivers/usb/gadget/function/f_hid.c | 50 ++++++++++++++++------------- > 1 file changed, 28 insertions(+), 22 deletions(-) > > diff --git a/drivers/usb/gadget/function/f_hid.c b/drivers/usb/gadget/function/f_hid.c > index ca0a7d9eaa34..0b94668a3812 100644 > --- a/drivers/usb/gadget/function/f_hid.c > +++ b/drivers/usb/gadget/function/f_hid.c > @@ -999,21 +1005,12 @@ static int hidg_bind(struct usb_configuration *c, struct usb_function *f) > > /* create char device */ > cdev_init(&hidg->cdev, &f_hidg_fops); > - dev = MKDEV(major, hidg->minor); > - status = cdev_add(&hidg->cdev, dev, 1); > + cdev_set_parent(&hidg->cdev, &hidg->dev.kobj); This line isn't needed; cdev_device_add() does it for you because hidg->dev.devt has been set. > + status = cdev_device_add(&hidg->cdev, &hidg->dev); > if (status) > goto fail_free_descs; > @@ -1277,17 +1272,28 @@ static struct usb_function *hidg_alloc(struct usb_function_instance *fi) > mutex_lock(&opts->lock); > ++opts->refcnt; > > - hidg->minor = opts->minor; > + device_initialize(&hidg->dev); > + hidg->dev.release = hidg_release; > + hidg->dev.class = hidg_class; > + hidg->dev.devt = MKDEV(major, opts->minor); > + ret = dev_set_name(&hidg->dev, "hidg%d", opts->minor); > + if (ret) { > + --opts->refcnt; > + mutex_unlock(&opts->lock); > + return ERR_PTR(ret); > + } > + Otherwise this looks okay (although I don't know any of the details of how fhidg works, so you shouldn't take my word for it). Alan Stern