Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3421069pxj; Sun, 20 Jun 2021 20:47:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzz2DqHKgmXqKLbBn2HlCgfNHvr8WOkiPGxsL3r3GjJ8H0T1dgyKe5GiewQwTm/yvSV57/p X-Received: by 2002:a17:906:2844:: with SMTP id s4mr22281352ejc.263.1624247258543; Sun, 20 Jun 2021 20:47:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624247258; cv=none; d=google.com; s=arc-20160816; b=Xe+4hE1bbVW70nZrkWkDa+ZRLQHiX5nqwcdqQ+O54gGYug9/liVnYoW3r5Nld34Lo4 KlY+Hr8e+6lX7Cw6NCcij4h0EcVncCTXnkzmAfsNlhWsT8YuMRLdAOU4ohjiWO/WFlcr sRfLES49WL+ojCga+69Brvy4bykmAiNmgziDdBY5hWqNIbRvJkGlc9BSRwabX8uNK14f sShhCWxha/bJVFqAZHWEqdv9IaMH9nZ4Do/uT61SIsrALeTJDV7rrmbg4+D9Q/y+Spm/ vLI091vRSVRAiQlgsVwzi9yO/O0WyGqweyYFlWXfgZLPolfv2i/RZJBITJCW56lAqkLg n5+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=bgDx2y7jnHVgqpuH7DSftkNRKg871OtZSQDSrAU/dKc=; b=WEkbf1uA+oHCkwOVis7259BYAyGf9QZJiSl+48lpjEFkH0PjSY4zAO/ZgZdMndBisM H1KE6rO673gkIhfNkXX1Gbu17SGegD/fgXPMUujWOKIbcki2iQuRw6EA6xWSSK8vXDO3 LGcCbnW8H9b8FEiO0wXsVyPoHbHeXToHlcdG1ZR3S9fAAqrTfuTE2lqlhiipBf9CSi2+ iwL4S9CaZqOwZeu/rijBmPlRH+EzWMQDqAQ3XQMfcssTnTH2IEakKdegMaa8M90DKsYf Oi9HWuO9r4fk0cpBeRD3ynsgp9k1z35Lp+TDOuRnmltBDDMiRSqoTcbR2hSIIKdmpGRh /Lnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RBgI4HZO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hx2si2220787ejc.155.2021.06.20.20.47.16; Sun, 20 Jun 2021 20:47:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RBgI4HZO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229968AbhFUDsR (ORCPT + 99 others); Sun, 20 Jun 2021 23:48:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229905AbhFUDsQ (ORCPT ); Sun, 20 Jun 2021 23:48:16 -0400 Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60520C061574 for ; Sun, 20 Jun 2021 20:46:02 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id j8so8469706vsd.0 for ; Sun, 20 Jun 2021 20:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bgDx2y7jnHVgqpuH7DSftkNRKg871OtZSQDSrAU/dKc=; b=RBgI4HZOPSLWFitfDhCXIi1mcWgVvf3+50V5tuKS/O8N8Nja87eY9XsQ8PGbHRDp9k ltUFHJ6eDpV4UUlkmvP+A9XJF+swllOumaSrn1A2bi46Ei36fhBwCYcWsZ+/AvAwEbz7 S0KYpU/qfIYt6V79RiP/1Ys3Qp2E2q79UeYI2trez2eKuLm74gbksVymh+y+rr/ZoZbz SS8fUnjBmIVwXjQk7sTIGSL5G0fM1mn0HzC8U4JP/nFQKza5qo+dG/eVtHxgzWg5tWU3 lFmOa1AqiIqNsFk81RdFuDYEZ8B8sENcTLkDcXXAlXlfDAoG33qm0J7n7NlnHj7NBUyV PLfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bgDx2y7jnHVgqpuH7DSftkNRKg871OtZSQDSrAU/dKc=; b=dZitw4NyWqM9IH6zyJt1YBUaA2dV+J/zX+kRiLbH9vPKDgYN682rF7BLZtK/YaBQAm EfInp6pdY8IOXMyOajhTnoQNRWIPnFz+rwVjDbmKkBDL4JVQAXpha3oSi+QnKMabddC3 dB1s2QhsZhHRe0FJgdd7N0WnZYw0pIWNEzsQvOuFo6ipRFEISm6H0WAbtUIhRrn8RL6h cjiuioGvxuzRWLJZuv6xL6hNl+Li3bi3M5hlMbsy18zWsr0sEDo0M+O2jGkToinzUVQJ cfIGpWCYDVCU8yPEs6qaVLVqXS/FfksXsHfvuHOuRW1sgUpiY+tyD7ZPr7dYvaXJYlw6 G5Ug== X-Gm-Message-State: AOAM53386zvnL5+eLTmtMW1SfiSnc18FQ6yvg9zP6eylDBxhPaFCFUmf ezPmzNZ1uSIBNxJGKG3URc9G7kwY22j3xIAuBjXxFA== X-Received: by 2002:a05:6102:3026:: with SMTP id v6mr5152176vsa.1.1624247161113; Sun, 20 Jun 2021 20:46:01 -0700 (PDT) MIME-Version: 1.0 References: <70042d9f.111abd.17a19f94b84.Coremail.linma@zju.edu.cn> In-Reply-To: <70042d9f.111abd.17a19f94b84.Coremail.linma@zju.edu.cn> From: "Anand K. Mistry" Date: Mon, 21 Jun 2021 13:45:48 +1000 Message-ID: Subject: Re: Re: [PATCH 5.4 39/78] Bluetooth: use correct lock to prevent UAF of hdev object To: LinMa Cc: Greg Kroah-Hartman , linux-kernel , stable Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Jun 2021 at 22:37, LinMa wrote: > > > Oops, sorry for the delay here. I just forgot to check the mails. > > This comment is right, when I submit this patch I mentioned that the repl= acement of this lock can hang the detaching routine because it needs to wai= t the release of the lock_sock(). > > But this does no harm in my testing. In fact, the relevant code can only = be executed when removing the controller. I think it can wait for the lock.= Moreover, this patch can fix the potential UAF indeed. > > > may need further discussion. (wrote in previous mail list > > Welcome the additional advise on this. Does this really broken the lock p= rinciple? One more data point. I'm seeing this 100% of the time when trying the suspend my system (on 5.10): [ 466.608970] BUG: sleeping function called from invalid context at net/core/sock.c:3074 [ 466.608975] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5614, name: kworker/u4:4 [ 466.608980] CPU: 1 PID: 5614 Comm: kworker/u4:4 Tainted: G W 5.10.43 #64 [ 466.608983] Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.104.0 09/05/2019 [ 466.608991] Workqueue: events_unbound async_run_entry_fn [ 466.608995] Call Trace: [ 466.609003] dump_stack+0x9c/0xe7 [ 466.609009] ___might_sleep+0x148/0x15e [ 466.609013] lock_sock_nested+0x22/0x5d [ 466.609033] hci_sock_dev_event+0x15a/0x1f0 [bluetooth] [ 466.609043] hci_unregister_dev+0x15c/0x303 [bluetooth] [ 466.609049] btusb_disconnect+0x77/0x127 [btusb] [ 466.609054] usb_unbind_interface+0xa6/0x22e [ 466.609059] ? usb_dev_suspend+0x14/0x14 [ 466.609063] device_release_driver_internal+0x100/0x1a1 [ 466.609067] unbind_marked_interfaces+0x4b/0x66 [ 466.609071] usb_resume+0x59/0x66 [ 466.609075] dpm_run_callback+0x8c/0x126 [ 466.609078] device_resume+0x1f1/0x25b [ 466.609082] async_resume+0x1d/0x42 [ 466.609085] async_run_entry_fn+0x3d/0xd1 [ 466.609089] process_one_work+0x1b9/0x363 [ 466.609093] worker_thread+0x213/0x372 [ 466.609097] kthread+0x150/0x15f [ 466.609100] ? pr_cont_work+0x58/0x58 [ 466.609103] ? kthread_blkcg+0x31/0x31 [ 466.609106] ret_from_fork+0x22/0x30 > > Regards Lin Ma > > =E5=9C=A8 2021-06-16 23:01:08=EF=BC=8C"Greg Kroah-Hartman" =E5=86=99=E9=81=93=EF=BC=9A > > >On Mon, Jun 14, 2021 at 04:15:02PM +0200, Eric Dumazet wrote: > >> > >> > >> On 6/8/21 8:27 PM, Greg Kroah-Hartman wrote: > >> > From: Lin Ma > >> > > >> > commit e305509e678b3a4af2b3cfd410f409f7cdaabb52 upstream. > >> > > >> > The hci_sock_dev_event() function will cleanup the hdev object for > >> > sockets even if this object may still be in used within the > >> > hci_sock_bound_ioctl() function, result in UAF vulnerability. > >> > > >> > This patch replace the BH context lock to serialize these affairs > >> > and prevent the race condition. > >> > > >> > Signed-off-by: Lin Ma > >> > Signed-off-by: Marcel Holtmann > >> > Signed-off-by: Greg Kroah-Hartman > >> > --- > >> > net/bluetooth/hci_sock.c | 4 ++-- > >> > 1 file changed, 2 insertions(+), 2 deletions(-) > >> > > >> > --- a/net/bluetooth/hci_sock.c > >> > +++ b/net/bluetooth/hci_sock.c > >> > @@ -755,7 +755,7 @@ void hci_sock_dev_event(struct hci_dev * > >> > /* Detach sockets from device */ > >> > read_lock(&hci_sk_list.lock); > >> > sk_for_each(sk, &hci_sk_list.head) { > >> > - bh_lock_sock_nested(sk); > >> > + lock_sock(sk); > >> > if (hci_pi(sk)->hdev =3D=3D hdev) { > >> > hci_pi(sk)->hdev =3D NULL; > >> > sk->sk_err =3D EPIPE; > >> > @@ -764,7 +764,7 @@ void hci_sock_dev_event(struct hci_dev * > >> > > >> > hci_dev_put(hdev); > >> > } > >> > - bh_unlock_sock(sk); > >> > + release_sock(sk); > >> > } > >> > read_unlock(&hci_sk_list.lock); > >> > } > >> > > >> > > >> > >> > >> This patch is buggy. > >> > >> lock_sock() can sleep. > >> > >> But the read_lock(&hci_sk_list.lock) two lines before is not going to = allow the sleep. > >> > >> Hmmm ? > >> > >> > > > >Odd, Lin, did you see any problems with your testing of this? > > --=20 Anand K. Mistry Software Engineer Google Australia