Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4636700iob; Sun, 8 May 2022 20:07:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyE6AP81sOnmeRUYHHSXCzng6wEZE2JRg9qHZIci6IIRrqJ3pPXkJo+hBhMy7ZAoSaW3TAE X-Received: by 2002:a17:902:ef50:b0:156:486f:b593 with SMTP id e16-20020a170902ef5000b00156486fb593mr14387036plx.104.1652065630565; Sun, 08 May 2022 20:07:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652065630; cv=none; d=google.com; s=arc-20160816; b=D4jrpSsdy0DzC0y3ugc/GU9LwWYRyuGygYvn9Q/5X0WCY4i33sstsPtNLSspYTyRD0 YVmlpGbS9txZ/QaYB5L+rE9T6dFx8NVTzVWUNIIGL0qSD5NQkfqqmU5wTdIw189kG3YA HLK5BxoGcfwVATkm+eZT3WjVowP+vh/afk5FUEZoYX3Mnk0T33o51X0D5I1yXsCJHfcL kcarfOaF4cvFD5+vTGKqrN4it0YcI4k2iBPdPinjSagdNAI8NiSSb/QDz6GEd/oQ29F7 YyAtqxrHiGrlLYTW1rZ56wMPfErk1LZJzkDwxQpyuoiqyMLcLRChKXE4GeHpDbhkJ+jJ qM7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=2hvTqYp3Vz8Ca80b3V7APOxJqJQJXmTRQa6QXcfz5js=; b=lgTfCfk0DV0PNdSwIhrsZPhCFE2sZWiKNdYeOF2oHw96yHsenYYRZHKhiqPlhuIMao bbvontK9C4bnsg6e1pPOKx2dSGYQG7kIJjO6sIkq89IJdLdEinyjFPOvkKKhbBte7l4O 2gFRjSbNvP4HIUSnxN7AzoBijG4mgVF0MBCPmegcPEIggwOuS83yvy2PsiDLRcYm1gCC 5gY3VhlmgSGqNZJMhKQMWjAgg20Qvwqj4Qwzg1bZTGdSYtpj1fJzkWIS5kur9w2cFBi5 pZe2zuA2FxWZYBq++f7C8bh6lM8SIW/HZtBmWc+qqEQDaRFil0a0MNrDDPKSK/Uk3UhW 4+gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=dwxji6Zp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id l16-20020a056a0016d000b004fa3a8e008esi14458868pfc.325.2022.05.08.20.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 20:07:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=dwxji6Zp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5F289338AA; Sun, 8 May 2022 20:05:32 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1385746AbiEGPry (ORCPT + 99 others); Sat, 7 May 2022 11:47:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230521AbiEGPrv (ORCPT ); Sat, 7 May 2022 11:47:51 -0400 Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 792512ED66; Sat, 7 May 2022 08:43:53 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id 88-20020a9d0ee1000000b005d0ae4e126fso6982687otj.5; Sat, 07 May 2022 08:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2hvTqYp3Vz8Ca80b3V7APOxJqJQJXmTRQa6QXcfz5js=; b=dwxji6ZpVZ7Y9GMHDIJA5ma8j2vg+MjD71ndkaRB69ti5zskIKEA/+Zq50N2ox2G+E QwnEpYkq65wXEz88VnKfbYFiF/8tyK8UidnyBG2wcS99HdmXWtIYXfMZwZ+0B9NfA4l/ +NnkTRXpY7GIjILlQW1aSSp4gF6XVZrFc4a5syDj036FPAd1BJWo12HUTuAVpuyxMhSZ DCHCXfBAn4wffJ66q/7wRxb/JA/Z5fnfr7fm1WEFY/GXWmcfd7O+jvQgJNMVpXdjQzvP WzlwQ/h3Eo82Qlao8IiGzltFN6Cxatm33QPZkQkYqCsrXOOyudb2gHfE+v+xxzksSTMH F3Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2hvTqYp3Vz8Ca80b3V7APOxJqJQJXmTRQa6QXcfz5js=; b=rE7xwIClVEJIg0Vsd2E382MB16R7uWaDjka4osUWp769uyn07wzsVekDQ/GRZIMi6O fJd9Schs18up9Exa5rXbKABj5cnEdkLgrGkQXq19w1fvr2e5yiJlsm9kRHpPRbpZ8nzX N4Pk7Ccj3Znvm2Y389fT9rGzcdDKmNgh39v0x4tUqZO6XnEt7jlX5g6o+SI/uUkbclG/ bz0dqpmYlEtgt37QOaNePQKe6YsowG0G+lXgCoZ/rBlYSaPx/480q3ePVvZSpr4MX/3c ZGJIy6FStraqQ3rL8oOxV6Sg0dCE0uA+4CtMJoPdugXhV7jPa7r67L8BaOOpy8Qfn5Kz pE2Q== X-Gm-Message-State: AOAM5312IO7cqZc4b2dI1AUH8WyleoqfCVTbNPvKZEiQ+PmJETI994qf G8R79yU/oinyEl1IrVRU71ew8YiVFFhvR9YTips= X-Received: by 2002:a05:6830:1183:b0:606:698:717e with SMTP id u3-20020a056830118300b006060698717emr2942155otq.309.1651938232783; Sat, 07 May 2022 08:43:52 -0700 (PDT) MIME-Version: 1.0 References: <20220507120851.29948-1-schspa@gmail.com> In-Reply-To: From: Schspa Shi Date: Sat, 7 May 2022 23:43:41 +0800 Message-ID: Subject: Re: [PATCH] usb: gadget: fix race when gadget driver register via ioctl To: Greg KH Cc: andreyknvl@gmail.com, balbi@kernel.org, jj251510319013@gmail.com, stern@rowland.harvard.edu, jannh@google.com, Julia.Lawall@inria.fr, linux-usb@vger.kernel.org, Linux Kernel Mailing List , syzbot+dc7c3ca638e773db07f6@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE 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 Greg KH writes: > On Sat, May 07, 2022 at 08:08:51PM +0800, Schspa Shi wrote: >> The usb_gadget_register_driver doesn't have inside locks to protect the >> driver, and If there is two threads are registered at the same time via >> the ioctl syscall, the system will crash as syzbot reported. >> >> Call trace as: >> driver_register+0x220/0x3a0 drivers/base/driver.c:171 >> usb_gadget_register_driver_owner+0xfb/0x1e0 >> drivers/usb/gadget/udc/core.c:1546 >> raw_ioctl_run drivers/usb/gadget/legacy/raw_gadget.c:513 [inline] >> raw_ioctl+0x1883/0x2730 drivers/usb/gadget/legacy/raw_gadget.c:1220 >> >> This routine allows two processes to register the same driver instance >> via ioctl syscall. which lead to a race condition. >> >> We can fix it by adding a driver_lock to avoid double register. >> >> Reported-by: syzbot+dc7c3ca638e773db07f6@syzkaller.appspotmail.com >> Link: https://lore.kernel.org/all/000000000000e66c2805de55b15a@google.com/ >> >> Signed-off-by: Schspa Shi >> --- >> drivers/usb/gadget/legacy/raw_gadget.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/usb/gadget/legacy/raw_gadget.c b/drivers/usb/gadget/legacy/raw_gadget.c >> index b3be8db1ff63..d7ff9c2b5397 100644 >> --- a/drivers/usb/gadget/legacy/raw_gadget.c >> +++ b/drivers/usb/gadget/legacy/raw_gadget.c >> @@ -155,7 +155,9 @@ struct raw_dev { >> spinlock_t lock; >> >> const char *udc_name; >> + /* Protected by driver_lock for reentrant registration */ >> struct usb_gadget_driver driver; >> + struct mutex driver_lock; > > Why are you adding another lock here? What's wrong with the existing > lock in this structure that requires an additional one? > We can't use the existing lock, because it's a spinlock, and can't call usb_gadget_register_driver() in its critical section, it will hold "udc_lock" which is a mutex_lock. Moreover, a deeper, it will call driver_register(), which can't be called by atomic context too. >> + mutex_lock(&dev->driver_lock); >> ret = usb_gadget_register_driver(&dev->driver); >> + mutex_unlock(&dev->driver_lock); > > How can unregister race with register? > I'm sorry for the confused race explanation, it's not unregister race with register, this lock around usb_gadget_unregister_driver() can be I will remove this lock in a new patchset if no other change needs to be made. > What ioctl is causing this race? What userspace program is doing this? > Only one userspace program should be accessing this at once, right? > > confused, It's because of two processes calling to register the same driver instance, which causes the race condition. The ioctl is USB_RAW_IOCTL_RUN, which can be called from userspace multi times or we should add protection to ioctl calls to avoid multi time device register? In this usb gadget, the driver property should be passed from USB_RAW_IOCTL_INIT ioctl, which leave here a device_register by userspace. For more details about this race. Process 0 Process 1 USB_RAW_IOCTL_INIT USB_RAW_IOCTL_RUN USB_RAW_IOCTL_RUN usb_gadget_register_driver usb_gadget_register_driver driver_register driver_register > > greg k-h --- BRs Schspa Shi