Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp4456601rwb; Tue, 6 Sep 2022 07:48:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR6idAz1qm94t0+Ee5tstbsFGhNR++A1ox0Qc0nhfnK7vKAqEUFNVvVVbPepTAj5iXObudbE X-Received: by 2002:a17:90a:d593:b0:200:b212:6eb2 with SMTP id v19-20020a17090ad59300b00200b2126eb2mr51687pju.60.1662475720324; Tue, 06 Sep 2022 07:48:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662475720; cv=none; d=google.com; s=arc-20160816; b=ePMXnU6Y4g3brYADqtJhtdGSm7tR9Pg/HdhnVSpHi5+wyNtky7nU0mO0kgbntLhtTw gKuUEUl6UQhH8ujnj8BelWyV7rQePI/hxnQh4kMjWjKOW/etlYzcduLHVg9I45ds143z 0v1F4Sk8AxTSoz45mda9PTAjocUdRxjYS2BZReIf+bEDRRLTc4MOX/cLDQ3R/BNxxNqZ IE51NtvKqan8bV3Sf/PMHGdJYIPLjihkNSMvPJ8ZOMzYMj4ho/kMst73PcFxd3RMaOtw h7mHU+7xThC4Cj1GysVtnUbBOA0meqYkuAGarJHJFE6hFdcBrYFfY6tb1ADnqD4oZRlv YXHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=uiSmcL8mjyvrltY0RsE/uwc4jgGSW/a6QRpEouRJ04Q=; b=x1hYlCtq6t/psM3MZ+4XKOVQXGqVC7r1+5q3/X6cWmSAEo9SjbALX1tMyL3JSRK73K MrBIZUCyDSDFKcrUGs4+v8IfSZ3h9fjHEs2x19U9nZnv6YJscb7wvNOiFN3K/ZnUww59 vocvajh9epxu7F6Ek9mUIzhArSopCk+EfudINiqKJ/XDQzirakoeptQdmuKohhNzEni7 8AGuHuPll4gCgiyKMwtYST+bVxzpOTdcPzwPS55rayk3Gh+7eiCq2JwPTsPKSw3WMCjp 4PjYi7AAd/q8HwRwcVMnNHEDO9TASN0Hke9iIOWUdc0rptYZdk/9bj7wvgn+TvcdJyVW rzYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="vewYOhq/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n15-20020a63ee4f000000b0042c3dd6e3ecsi14403109pgk.527.2022.09.06.07.48.27; Tue, 06 Sep 2022 07:48:40 -0700 (PDT) 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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="vewYOhq/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241265AbiIFONT (ORCPT + 99 others); Tue, 6 Sep 2022 10:13:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241255AbiIFOMP (ORCPT ); Tue, 6 Sep 2022 10:12:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C617B883C1; Tue, 6 Sep 2022 06:47:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 563E261562; Tue, 6 Sep 2022 13:47:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63CCAC433D6; Tue, 6 Sep 2022 13:47:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662472053; bh=Vng8UDcCk4seBfMkv1zHG4Ccf9Mzg8uCPneVyyniLeA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vewYOhq//zFoHbJ4Dk/kISxlvd7VTnYO+Ru0kOyp6Z1Wac2jpkfashgu4mCdYMQWw 98YJ7t78nSUrXsIVZTk6qLMFaM95FQZM0xK9+aYvB1h2pGEZtlJ6ZErt8NLrRkuFvu xs1kZFGrvNLvM/AFX8WlF68K7kqnAE172xcgDjLQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , Rondreis Subject: [PATCH 5.19 130/155] USB: core: Prevent nested device-reset calls Date: Tue, 6 Sep 2022 15:31:18 +0200 Message-Id: <20220906132834.952631116@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220906132829.417117002@linuxfoundation.org> References: <20220906132829.417117002@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 From: Alan Stern commit 9c6d778800b921bde3bff3cff5003d1650f942d1 upstream. Automatic kernel fuzzing revealed a recursive locking violation in usb-storage: ============================================ WARNING: possible recursive locking detected 5.18.0 #3 Not tainted -------------------------------------------- kworker/1:3/1205 is trying to acquire lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 but task is already holding lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... stack backtrace: CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 This turned out not to be an error in usb-storage but rather a nested device reset attempt. That is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that driver does not have pre_reset or post_reset callbacks), its ->remove routine called usb_reset_device() -- thus nesting one reset call within another. Performing a reset as part of disconnect processing is a questionable practice at best. However, the bug report points out that the USB core does not have any protection against nested resets. Adding a reset_in_progress flag and testing it will prevent such errors in the future. Link: https://lore.kernel.org/all/CAB7eexKUpvX-JNiLzhXBDWgfg2T9e9_0Tw4HQ6keN==voRbP0g@mail.gmail.com/ Cc: stable@vger.kernel.org Reported-and-tested-by: Rondreis Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/YwkflDxvg0KWqyZK@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/hub.c | 10 ++++++++++ include/linux/usb.h | 2 ++ 2 files changed, 12 insertions(+) --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -6048,6 +6048,11 @@ re_enumerate: * the reset is over (using their post_reset method). * * Return: The same as for usb_reset_and_verify_device(). + * However, if a reset is already in progress (for instance, if a + * driver doesn't have pre_ or post_reset() callbacks, and while + * being unbound or re-bound during the ongoing reset its disconnect() + * or probe() routine tries to perform a second, nested reset), the + * routine returns -EINPROGRESS. * * Note: * The caller must own the device lock. For example, it's safe to use @@ -6081,6 +6086,10 @@ int usb_reset_device(struct usb_device * return -EISDIR; } + if (udev->reset_in_progress) + return -EINPROGRESS; + udev->reset_in_progress = 1; + port_dev = hub->ports[udev->portnum - 1]; /* @@ -6145,6 +6154,7 @@ int usb_reset_device(struct usb_device * usb_autosuspend_device(udev); memalloc_noio_restore(noio_flag); + udev->reset_in_progress = 0; return ret; } EXPORT_SYMBOL_GPL(usb_reset_device); --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -575,6 +575,7 @@ struct usb3_lpm_parameters { * @devaddr: device address, XHCI: assigned by HW, others: same as devnum * @can_submit: URBs may be submitted * @persist_enabled: USB_PERSIST enabled for this device + * @reset_in_progress: the device is being reset * @have_langid: whether string_langid is valid * @authorized: policy has said we can use it; * (user space) policy determines if we authorize this device to be @@ -661,6 +662,7 @@ struct usb_device { unsigned can_submit:1; unsigned persist_enabled:1; + unsigned reset_in_progress:1; unsigned have_langid:1; unsigned authorized:1; unsigned authenticated:1;