Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp193028pxt; Wed, 4 Aug 2021 08:51:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9Sex2QFUDcRjy2EJhFKnJxDDtb//tNc06ji/M7YC2dXujjAsqw1UPjmm2uCtkMfRA1So5 X-Received: by 2002:a17:907:3d91:: with SMTP id he17mr26781507ejc.355.1628092260391; Wed, 04 Aug 2021 08:51:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628092260; cv=none; d=google.com; s=arc-20160816; b=G5bzAA6a4yoWQMsllingQYw4E1E1qty2Qvb3vs1kPuroHYmAZD97rvIf8h7TKyneHK zo2Zzs6Ib3DGgYYYi71qWINHHHHD7VtD0b26nMA3QVYgHQBUVV44xadzi8Xlp3wmVO16 JMiNR7X4RzfLgYWIMrDqR1D3hR2359LWtv9ay1UX+zweQ3kO5jFkp+ILKsgNGJHkMkhg xaJUPjdbSDdlCAaW+3iuL/0sv8KBh70Zpbb0Kut/SYB2pAVRwBUhwUD1LMZkubBI1EM8 ETmdFllZFqTR/Ob2WcuY6VKvXbY7sACiEfisCaDHBbS5YtFTuAygSe4miBJv84AsW3oE 6yzA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=srAeYY/EiQIT3OULRf8vlai9yqHxF+kaop05ae2z79I=; b=SkrjwJdoOKQmmmMsIXcav4x6d17iet63Lar+5tFHtUWNd+rTI1OyGNSuMdndqB7kI/ w6jqnOrphVCGW+p49tQ5grk8jshZe1l/FhOB0VwQbdlWAwIepIpyUawjLlaq45kgrvGU MxyHn05J7XsBz8pwlxNScPvsfygpb+AoKac4DGDWHJ+ImpQAR/PP6iU8Cd2AQeUaRP1q CRqd0Vruqck6Qc2/gSk80CQy6FWcW/y+GEGg9GQ6joXnu4yaA2L1uvdNmhrcwOr8OnnZ r1xRnd17phFoNhEHFJCmDrSAK7YahdNOkJrvlKWDncjbhRj8+NBKXQNxamMvLHuI+fvS Abzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VYfLn0s4; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j20si2585153ejv.108.2021.08.04.08.50.36; Wed, 04 Aug 2021 08:51:00 -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=@gmail.com header.s=20161025 header.b=VYfLn0s4; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239391AbhHDPst (ORCPT + 99 others); Wed, 4 Aug 2021 11:48:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239383AbhHDPss (ORCPT ); Wed, 4 Aug 2021 11:48:48 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2A8EC06179B; Wed, 4 Aug 2021 08:48:34 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id d1so3472630pll.1; Wed, 04 Aug 2021 08:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=srAeYY/EiQIT3OULRf8vlai9yqHxF+kaop05ae2z79I=; b=VYfLn0s4o2Go241cmmAwbVoaNXcWbuvcxb7ttLjpBumxdXVxVaRYGolXGBzKUMpoa6 z9AbtDtq7uF6W/PCu/WNstLyO4+LNSyxw1b5fKI0+YfNQmk144f6XnEoVtf0BeHzFxvn 64H9s1kJgf+ZYm4+M53Yt0YIHGEDygcFguy5LjLf5Nwx0xJjYYdtFV0iP7R1so6oxEAR 2wXVKN2K/Lu8ZdZOUPBzKPNxXZBfa/ghHdWq+Jzx1S/flTyEYlpqYL+T6FTV5n5eJGbN FgF/mbl6UzMwmXV50fFIEN4pHixgITcqX70ZLMItkiJE4iBFjgEJKzrpIdCLynQA+jOn Y/zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=srAeYY/EiQIT3OULRf8vlai9yqHxF+kaop05ae2z79I=; b=PLhXoc1kWhpi/qw5eYfMviqzZT4e894Akt/JQD8K8B7Z6LF/PYjUOJWOPRS7KyzhL4 bFXnKsjMQnZB5jVH512aGaVo25dNPB+eILIY3zUaxswU7nG+QzT9cN9oJwVFbN5mcjaY j4vCuNZFN8DyxWTmfHSMNIiv4odk502U3cMPNuIeRhbD3tWFYhj+/G9J3kRP0RqCnOvb 2oTsBn+oI1N0pLHUcMWMccfc2HXnleBFUK9wiuoxxPma9zXdQ1EFvKn6eEQKKQh9L1qH ujWhY9WdmltbCcFEO1jopmH15hEY4/fldte6UM8V4kdaIY1MiI07opDxJXnKHuQTD1fD Sw3g== X-Gm-Message-State: AOAM532B23qGvyFmB/BDkL7ukH7To4N09nXX8e2r4EgxLYbFTF4SkOfx 7HHGVYVvM05pxxGYuUJoDwqf2QPfvot3tLSZDJo= X-Received: by 2002:a17:903:1243:b029:107:eca4:d5bf with SMTP id u3-20020a1709031243b0290107eca4d5bfmr260942plh.15.1628092114325; Wed, 04 Aug 2021 08:48:34 -0700 (PDT) Received: from localhost.localdomain ([118.200.190.93]) by smtp.gmail.com with ESMTPSA id b15sm4007274pgj.60.2021.08.04.08.48.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Aug 2021 08:48:33 -0700 (PDT) From: Desmond Cheong Zhi Xi To: marcel@holtmann.org, johan.hedberg@gmail.com, luiz.dentz@gmail.com, davem@davemloft.net, kuba@kernel.org, sudipm.mukherjee@gmail.com Cc: Desmond Cheong Zhi Xi , linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org, gregkh@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org, syzbot+2f6d7c28bb4bf7e82060@syzkaller.appspotmail.com Subject: [RESEND PATCH v5 1/6] Bluetooth: schedule SCO timeouts with delayed_work Date: Wed, 4 Aug 2021 23:47:07 +0800 Message-Id: <20210804154712.929986-2-desmondcheongzx@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210804154712.929986-1-desmondcheongzx@gmail.com> References: <20210804154712.929986-1-desmondcheongzx@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org struct sock.sk_timer should be used as a sock cleanup timer. However, SCO uses it to implement sock timeouts. This causes issues because struct sock.sk_timer's callback is run in an IRQ context, and the timer callback function sco_sock_timeout takes a spin lock on the socket. However, other functions such as sco_conn_del and sco_conn_ready take the spin lock with interrupts enabled. This inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} lock usage could lead to deadlocks as reported by Syzbot [1]: CPU0 ---- lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(slock-AF_BLUETOOTH-BTPROTO_SCO); To fix this, we use delayed work to implement SCO sock timouts instead. This allows us to avoid taking the spin lock on the socket in an IRQ context, and corrects the misuse of struct sock.sk_timer. As a note, cancel_delayed_work is used instead of cancel_delayed_work_sync in sco_sock_set_timer and sco_sock_clear_timer to avoid a deadlock. In the future, the call to bh_lock_sock inside sco_sock_timeout should be changed to lock_sock to synchronize with other functions using lock_sock. However, since sco_sock_set_timer and sco_sock_clear_timer are sometimes called under the locked socket (in sco_connect and __sco_sock_close), cancel_delayed_work_sync might cause them to sleep until an sco_sock_timeout that has started finishes running. But sco_sock_timeout would also sleep until it can grab the lock_sock. Using cancel_delayed_work is fine because sco_sock_timeout does not change from run to run, hence there is no functional difference between: 1. waiting for a timeout to finish running before scheduling another timeout 2. scheduling another timeout while a timeout is running. Link: https://syzkaller.appspot.com/bug?id=9089d89de0502e120f234ca0fc8a703f7368b31e [1] Reported-by: syzbot+2f6d7c28bb4bf7e82060@syzkaller.appspotmail.com Tested-by: syzbot+2f6d7c28bb4bf7e82060@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi --- net/bluetooth/sco.c | 41 +++++++++++++++++++++++++++++++++++------ 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c index ffa2a77a3e4c..89cb987ca9eb 100644 --- a/net/bluetooth/sco.c +++ b/net/bluetooth/sco.c @@ -48,6 +48,8 @@ struct sco_conn { spinlock_t lock; struct sock *sk; + struct delayed_work timeout_work; + unsigned int mtu; }; @@ -74,9 +76,20 @@ struct sco_pinfo { #define SCO_CONN_TIMEOUT (HZ * 40) #define SCO_DISCONN_TIMEOUT (HZ * 2) -static void sco_sock_timeout(struct timer_list *t) +static void sco_sock_timeout(struct work_struct *work) { - struct sock *sk = from_timer(sk, t, sk_timer); + struct sco_conn *conn = container_of(work, struct sco_conn, + timeout_work.work); + struct sock *sk; + + sco_conn_lock(conn); + sk = conn->sk; + if (sk) + sock_hold(sk); + sco_conn_unlock(conn); + + if (!sk) + return; BT_DBG("sock %p state %d", sk, sk->sk_state); @@ -91,14 +104,27 @@ static void sco_sock_timeout(struct timer_list *t) static void sco_sock_set_timer(struct sock *sk, long timeout) { + struct delayed_work *work; + + if (!sco_pi(sk)->conn) + return; + work = &sco_pi(sk)->conn->timeout_work; + BT_DBG("sock %p state %d timeout %ld", sk, sk->sk_state, timeout); - sk_reset_timer(sk, &sk->sk_timer, jiffies + timeout); + cancel_delayed_work(work); + schedule_delayed_work(work, timeout); } static void sco_sock_clear_timer(struct sock *sk) { + struct delayed_work *work; + + if (!sco_pi(sk)->conn) + return; + work = &sco_pi(sk)->conn->timeout_work; + BT_DBG("sock %p state %d", sk, sk->sk_state); - sk_stop_timer(sk, &sk->sk_timer); + cancel_delayed_work(work); } /* ---- SCO connections ---- */ @@ -179,6 +205,9 @@ static void sco_conn_del(struct hci_conn *hcon, int err) bh_unlock_sock(sk); sco_sock_kill(sk); sock_put(sk); + + /* Ensure no more work items will run before freeing conn. */ + cancel_delayed_work_sync(&conn->timeout_work); } hcon->sco_data = NULL; @@ -193,6 +222,8 @@ static void __sco_chan_add(struct sco_conn *conn, struct sock *sk, sco_pi(sk)->conn = conn; conn->sk = sk; + INIT_DELAYED_WORK(&conn->timeout_work, sco_sock_timeout); + if (parent) bt_accept_enqueue(parent, sk, true); } @@ -500,8 +531,6 @@ static struct sock *sco_sock_alloc(struct net *net, struct socket *sock, sco_pi(sk)->setting = BT_VOICE_CVSD_16BIT; - timer_setup(&sk->sk_timer, sco_sock_timeout, 0); - bt_sock_link(&sco_sk_list, sk); return sk; } -- 2.25.1