Message ID | 20230119013405.3870506-1-iam@sung-woo.kim |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp85773wrn; Wed, 18 Jan 2023 17:52:10 -0800 (PST) X-Google-Smtp-Source: AMrXdXv18tg2iZ0ZRkDIozwbAdRAxjhBgqwyea8QdsQ6RdIpHy2TQm0aK9/T7hUqBWW3CAz8EBv8 X-Received: by 2002:a17:90a:9c7:b0:229:3660:1759 with SMTP id 65-20020a17090a09c700b0022936601759mr9976739pjo.25.1674093130029; Wed, 18 Jan 2023 17:52:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674093130; cv=none; d=google.com; s=arc-20160816; b=WDGIherZTnr6+02djE8dEbEN8CsDFT8QcB2h+9J0RtnaHzlzFBu6pBc2PZwP3eRFbF 7Tv9m3oSTzI/LDLyoMRMEFoJuPLo6G3uchyw/VH1X1mhTMEO7f8ogri6PFG8HmyLUV7q 2LToAtE8oXQJW0E40NN8WDPdKEVy2WnUBXeS5yNfZxbI66g9kC9xTfirD22Q/nA6sCWy ANgJ6llRWCatUsxt1floEoVg+9TZjB6D6Z18SqStI4dArLN5VauPOmJmGymMYcF0V6I0 NC2jVF7O0zY0fOe6LlQ6S4P9jMZ69Ae+jWxolPUO4yX4p+yjDCNBAFPuIjZ8psxva0pg Ukmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:content-transfer-encoding:mime-version :message-id:date:subject:cc:from; bh=tcLHpnRNh3ty5rv7JErXW5X+LMKRtJ6Ae8+AonT+Wt4=; b=XlQaBgYpgTd1f4/OTN1tsr6V6Ewpc08uaa4Zb9KV/6Nr006qh/dwuR1x+BvfmNpzFn uFHOHx2K7nShnE6Aq1IxUCOtS90sqhbcw2ZnYPNqo/BYha4u3cBFOmc5QZoOGLv/hrdV twl/PnkBDgD3s8Eqa+lx+YQndbl7pviPfEXQmG+NUqLVF6/xc53yBjSQcEqZaSqelMk2 rH1xPThbMxKnIZ0Y8mSTqr/SO8fwpQMpT6GLNBEMiB5jgjo/vxpFbZQM4qCdjO0f3qZc 1LSvz5F2o2OaMZMVVQ6L4M9/f3xUXUHqWkO2qrDoCv8NuZiohR3hH1UlAdiMALckK4WB vcxg== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c17-20020a63d151000000b004785d1e2b7bsi36005259pgj.514.2023.01.18.17.51.53; Wed, 18 Jan 2023 17:52:10 -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 S229528AbjASBh4 (ORCPT <rfc822;pfffrao@gmail.com> + 99 others); Wed, 18 Jan 2023 20:37:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229899AbjASBfs (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 18 Jan 2023 20:35:48 -0500 Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D631665AC; Wed, 18 Jan 2023 17:35:46 -0800 (PST) Received: by mail-il1-f179.google.com with SMTP id p12so487523ilq.10; Wed, 18 Jan 2023 17:35:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tcLHpnRNh3ty5rv7JErXW5X+LMKRtJ6Ae8+AonT+Wt4=; b=0jLa0aGyVKMnt4/0y0IWTAk3bDxbSkFR0OThuSTTcKbqr3Vp/umF+56yBIgQT+wncE 9VcozD8zQMNki1kQCYc/uiQEVqjlzUiys0nVyCbaN+Wh02A2uUCcOmahXXdOz5N0Tkhl boCWyHypS7aGaspb39mZmvhXYQSIgYqOdd2yqoSgXPCBbVr+g3Adu9xhM6foy7j0oqwT gUeStPSpjBJxe31zJ5yMLtwuIjqfMCHYJ3j8Y6qxN+B0l62eZXkohMHOdpI+8sQCSE8D WvVMbfiYl9/bMPZRk4LXmORvhUatK9i0Xtmn7h/8pDVf+7pjzLOPJfqfjOKmUOUO1REX J/6Q== X-Gm-Message-State: AFqh2krR2gR//MhucOdkk6bRryC69FI7CZ3P4AvPK+0nkkA71TcYIPoM K4eirovp6NRuwyCASLUHyxg= X-Received: by 2002:a05:6e02:2191:b0:30f:12c9:f767 with SMTP id j17-20020a056e02219100b0030f12c9f767mr9659967ila.11.1674092145973; Wed, 18 Jan 2023 17:35:45 -0800 (PST) Received: from noodle.cs.purdue.edu (switch-lwsn2133-z1r11.cs.purdue.edu. [128.10.127.250]) by smtp.googlemail.com with ESMTPSA id cs10-20020a056638470a00b0039d756fb908sm3547284jab.40.2023.01.18.17.35.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 17:35:44 -0800 (PST) From: Sungwoo Kim <iam@sung-woo.kim> Cc: daveti@purdue.edu, wuruoyu@me.com, benquike@gmail.com, Sungwoo Kim <iam@sung-woo.kim>, Marcel Holtmann <marcel@holtmann.org>, Johan Hedberg <johan.hedberg@gmail.com>, Luiz Augusto von Dentz <luiz.dentz@gmail.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, linux-bluetooth@vger.kernel.org (open list:BLUETOOTH SUBSYSTEM), netdev@vger.kernel.org (open list:NETWORKING [GENERAL]), linux-kernel@vger.kernel.org (open list) Subject: [PATCH] L2CAP: Fix null-ptr-deref in l2cap_sock_set_shutdown_cb Date: Wed, 18 Jan 2023 20:34:05 -0500 Message-Id: <20230119013405.3870506-1-iam@sung-woo.kim> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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 To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755413877926323450?= X-GMAIL-MSGID: =?utf-8?q?1755413877926323450?= |
Series |
L2CAP: Fix null-ptr-deref in l2cap_sock_set_shutdown_cb
|
|
Commit Message
Sungwoo Kim
Jan. 19, 2023, 1:34 a.m. UTC
The L2CAP socket shutdown invokes l2cap_sock_destruct without a lock
on conn->chan_lock, assigning NULL to chan->data *just before*
the l2cap_disconnect_req thread that accesses to chan->data.
This patch prevent it by adding a null check for a workaround, instead
of fixing a lock.
This bug is found by FuzzBT, a modified Syzkaller by Sungwoo Kim(me).
Ruoyu Wu(wuruoyu@me.com) and Hui Peng(benquike@gmail.com) has helped
the FuzzBT project.
Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
---
net/bluetooth/l2cap_sock.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
Comments
Write of size 4 at addr 0000000000000098 by task kworker/u3:0/76 CPU: 0 PID: 76 Comm: kworker/u3:0 Not tainted 6.1.0-rc2 #129 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: hci0 hci_rx_work Call Trace: <TASK> dump_stack_lvl+0x7b/0xb3 print_report+0xed/0x200 ? __virt_addr_valid+0x5c/0x240 ? kasan_addr_to_slab+0xd/0xa0 ? _raw_spin_lock_bh+0x4c/0xc0 kasan_report+0xd3/0x100 ? _raw_spin_lock_bh+0x4c/0xc0 kasan_check_range+0x2d3/0x310 __kasan_check_write+0x14/0x20 _raw_spin_lock_bh+0x4c/0xc0 lock_sock_nested+0x3f/0x160 ? queue_work_on+0x90/0xd0 l2cap_sock_set_shutdown_cb+0x3d/0x60 l2cap_disconnect_req+0x1e3/0x2e0 l2cap_bredr_sig_cmd+0x3d2/0x5ec0 ? vprintk_emit+0x29b/0x4d0 ? vprintk_default+0x2b/0x30 ? vprintk+0xdc/0x100 ? _printk+0x67/0x85 ? bt_err+0x7f/0xc0 ? bt_err+0x9a/0xc0 l2cap_recv_frame+0x7bc/0x4e10 ? _printk+0x67/0x85 ? bt_err+0x7f/0xc0 ? __wake_up_klogd+0xc4/0xf0 l2cap_recv_acldata+0x327/0x650 ? hci_conn_enter_active_mode+0x1b7/0x1f0 hci_rx_work+0x6b7/0x7c0 process_one_work+0x461/0xaf0 worker_thread+0x5f8/0xba0 kthread+0x1c5/0x200 ? process_one_work+0xaf0/0xaf0 ? kthread_blkcg+0x90/0x90 ret_from_fork+0x1f/0x30 </TASK>
On Thu, Jan 19, 2023 at 2:41 AM Sungwoo Kim <iam@sung-woo.kim> wrote: > > Write of size 4 at addr 0000000000000098 by task kworker/u3:0/76 > > CPU: 0 PID: 76 Comm: kworker/u3:0 Not tainted 6.1.0-rc2 #129 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 > Workqueue: hci0 hci_rx_work > Call Trace: > <TASK> > dump_stack_lvl+0x7b/0xb3 > print_report+0xed/0x200 > ? __virt_addr_valid+0x5c/0x240 > ? kasan_addr_to_slab+0xd/0xa0 > ? _raw_spin_lock_bh+0x4c/0xc0 > kasan_report+0xd3/0x100 > ? _raw_spin_lock_bh+0x4c/0xc0 > kasan_check_range+0x2d3/0x310 > __kasan_check_write+0x14/0x20 > _raw_spin_lock_bh+0x4c/0xc0 > lock_sock_nested+0x3f/0x160 > ? queue_work_on+0x90/0xd0 > l2cap_sock_set_shutdown_cb+0x3d/0x60 > l2cap_disconnect_req+0x1e3/0x2e0 > l2cap_bredr_sig_cmd+0x3d2/0x5ec0 > ? vprintk_emit+0x29b/0x4d0 > ? vprintk_default+0x2b/0x30 > ? vprintk+0xdc/0x100 > ? _printk+0x67/0x85 > ? bt_err+0x7f/0xc0 > ? bt_err+0x9a/0xc0 > l2cap_recv_frame+0x7bc/0x4e10 > ? _printk+0x67/0x85 > ? bt_err+0x7f/0xc0 > ? __wake_up_klogd+0xc4/0xf0 > l2cap_recv_acldata+0x327/0x650 > ? hci_conn_enter_active_mode+0x1b7/0x1f0 > hci_rx_work+0x6b7/0x7c0 > process_one_work+0x461/0xaf0 > worker_thread+0x5f8/0xba0 > kthread+0x1c5/0x200 > ? process_one_work+0xaf0/0xaf0 > ? kthread_blkcg+0x90/0x90 > ret_from_fork+0x1f/0x30 > </TASK> If you plan sending more stack traces like that in the future, always run scripts/decode_stacktrace.sh so that the public report includes symbols. Thanks.
On Thu, Jan 19, 2023 at 2:35 AM Sungwoo Kim <iam@sung-woo.kim> wrote: > > The L2CAP socket shutdown invokes l2cap_sock_destruct without a lock > on conn->chan_lock, assigning NULL to chan->data *just before* > the l2cap_disconnect_req thread that accesses to chan->data. This is racy then ? > This patch prevent it by adding a null check for a workaround, instead > of fixing a lock. This would at least require some barriers I think. What about other _cb helpers also reading/using chan->data ? > > This bug is found by FuzzBT, a modified Syzkaller by Sungwoo Kim(me). > Ruoyu Wu(wuruoyu@me.com) and Hui Peng(benquike@gmail.com) has helped > the FuzzBT project. > > Signed-off-by: Sungwoo Kim <iam@sung-woo.kim> I would also add Fixes: 1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()") > --- > net/bluetooth/l2cap_sock.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c > index ca8f07f35..350c7afdf 100644 > --- a/net/bluetooth/l2cap_sock.c > +++ b/net/bluetooth/l2cap_sock.c > @@ -1681,9 +1681,11 @@ static void l2cap_sock_set_shutdown_cb(struct l2cap_chan *chan) > { > struct sock *sk = chan->data; > Other similar fixes simply do: if (!sk) return; I would chose to use the same coding style in net/bluetooth/l2cap_sock.c > - lock_sock(sk); > - sk->sk_shutdown = SHUTDOWN_MASK; > - release_sock(sk); > + if (!sk) { > + lock_sock(sk); > + sk->sk_shutdown = SHUTDOWN_MASK; > + release_sock(sk); > + } > } > > static long l2cap_sock_get_sndtimeo_cb(struct l2cap_chan *chan) > -- > 2.25.1 >
Hi Kim, Eric, On Wed, Jan 18, 2023 at 8:16 PM Eric Dumazet <edumazet@google.com> wrote: > > On Thu, Jan 19, 2023 at 2:35 AM Sungwoo Kim <iam@sung-woo.kim> wrote: > > > > The L2CAP socket shutdown invokes l2cap_sock_destruct without a lock > > on conn->chan_lock, assigning NULL to chan->data *just before* > > the l2cap_disconnect_req thread that accesses to chan->data. > > This is racy then ? > > > This patch prevent it by adding a null check for a workaround, instead > > of fixing a lock. > > This would at least require some barriers I think. > > What about other _cb helpers also reading/using chan->data ? Perhaps it would be a good idea to include the stack backtrace so we can better understand it, at some point we might need to refactor or locks to avoid circular dependencies. > > > > This bug is found by FuzzBT, a modified Syzkaller by Sungwoo Kim(me). > > Ruoyu Wu(wuruoyu@me.com) and Hui Peng(benquike@gmail.com) has helped > > the FuzzBT project. > > > > Signed-off-by: Sungwoo Kim <iam@sung-woo.kim> > > I would also add > > Fixes: 1bff51ea59a9 ("Bluetooth: fix use-after-free error in > lock_sock_nested()") +1 > > --- > > net/bluetooth/l2cap_sock.c | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c > > index ca8f07f35..350c7afdf 100644 > > --- a/net/bluetooth/l2cap_sock.c > > +++ b/net/bluetooth/l2cap_sock.c > > @@ -1681,9 +1681,11 @@ static void l2cap_sock_set_shutdown_cb(struct l2cap_chan *chan) > > { > > struct sock *sk = chan->data; > > > > Other similar fixes simply do: > > if (!sk) > return; > > I would chose to use the same coding style in net/bluetooth/l2cap_sock.c Yep, at least l2cap_sock_close_cb and l2cap_sock_shutdown do that already. > > > - lock_sock(sk); > > - sk->sk_shutdown = SHUTDOWN_MASK; > > - release_sock(sk); > > + if (!sk) { > > + lock_sock(sk); > > + sk->sk_shutdown = SHUTDOWN_MASK; > > + release_sock(sk); > > + } > > } > > > > static long l2cap_sock_get_sndtimeo_cb(struct l2cap_chan *chan) > > -- > > 2.25.1 > >
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c index ca8f07f35..350c7afdf 100644 --- a/net/bluetooth/l2cap_sock.c +++ b/net/bluetooth/l2cap_sock.c @@ -1681,9 +1681,11 @@ static void l2cap_sock_set_shutdown_cb(struct l2cap_chan *chan) { struct sock *sk = chan->data; - lock_sock(sk); - sk->sk_shutdown = SHUTDOWN_MASK; - release_sock(sk); + if (!sk) { + lock_sock(sk); + sk->sk_shutdown = SHUTDOWN_MASK; + release_sock(sk); + } } static long l2cap_sock_get_sndtimeo_cb(struct l2cap_chan *chan)