From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4F74C25B0C for ; Thu, 11 Aug 2022 16:25:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238117AbiHKQZW (ORCPT ); Thu, 11 Aug 2022 12:25:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237714AbiHKQY0 (ORCPT ); Thu, 11 Aug 2022 12:24:26 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id D04F31AF25 for ; Thu, 11 Aug 2022 09:06:07 -0700 (PDT) Received: (qmail 8212 invoked by uid 1000); 11 Aug 2022 12:06:06 -0400 Date: Thu, 11 Aug 2022 12:06:06 -0400 From: Alan Stern To: Marek Szyprowski Cc: Greg KH , Felipe Balbi , Peter Zijlstra , USB mailing list , syzkaller-bugs@googlegroups.com Subject: Re: [PATCH] USB: gadget: Fix use-after-free Read in usb_udc_uevent() Message-ID: References: <000000000000acc0e905e4517fa0@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Thu, Aug 11, 2022 at 09:31:34AM +0200, Marek Szyprowski wrote: > Hi Alan, > > On 10.08.2022 21:33, Alan Stern wrote: > > On Mon, Aug 08, 2022 at 04:26:49PM -0400, Alan Stern wrote: > >> On Mon, Aug 08, 2022 at 04:57:35PM +0200, Marek Szyprowski wrote: > >>> This patch landed recently in linux-next as commit 2191c00855b0 ("USB: > >>> gadget: Fix use-after-free Read in usb_udc_uevent()"). Unfortunately it > >>> fixes the issue by introducing another one. It doesn't look very > >>> probable, but it would be nice to fix it to make the lock dependency > >>> checker happy. > >> Indeed. > >> I suspect the problem is that udc_lock is held for too long. Probably it > >> should be released during the calls to udc->driver->bind and > >> udc->driver->unbind. > >> > >> Getting this right will require some careful study. Marek, if I send you > >> a patch later, will you be able to test it? > > Here's a patch for you to try, when you have the chance. It reduces the > > scope of udc_lock to cover only the fields it's supposed to protect and > > changes the locking in a few other places. > > > > There's still the possibility of a locking cycle, because udc_lock is > > held in the ->disconnect pathway. It's very hard to know whether that > > might cause any trouble; it depends on how the function drivers handle > > disconnections. > > It looks this fixed the issue I've reported. I've checked it on all my > test systems and none reported any issue related to the udc. > > Feel free to add: > > Reported-by: Marek Szyprowski > > Tested-by: Marek Szyprowski Thanks for the quick testing. I'll submit the patch when the current merge window ends. Alan Stern