Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Ruihan Li <lrh2000@pku.edu.cn>
To:     linux-bluetooth@vger.kernel.org, luiz.dentz@gmail.com,
        johan.hedberg@gmail.com, marcel@holtmann.org
Cc:     syzbot+cf54c1da6574b6c1b049@syzkaller.appspotmail.com,
        davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        pabeni@redhat.com, syzkaller-bugs@googlegroups.com,
        Ruihan Li <lrh2000@pku.edu.cn>
Subject: Re: [syzbot] [bluetooth?] KASAN: slab-use-after-free Write in sco_chan_del
Date:   Tue, 16 May 2023 00:01:19 +0800
Message-Id: <20230515160119.38957-1-lrh2000@pku.edu.cn>
In-Reply-To: <00000000000013b93805fbbadc50@google.com>
References: <00000000000013b93805fbbadc50@google.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

It seems that, while we remember to release unestablished SCO connections when
the ACL connection tears down (since [1]), we forget to call hci_connect_cfm
before hci_conn_del. Without hci_connect_cfm, the SCO socket may not be
notified to clean up its associated SCO connection (in sco_connect_cfm),
causing this use-after-free risk when operating the socket.

 [1] https://lore.kernel.org/linux-bluetooth/20230203173024.1.Ieb6662276f3bd3d79e9134ab04523d584c300c45@changeid/

However, I cannot figure out an easy and clear way to pass a proper error code
to hci_connect_cfm at this point, so I wonder if it is acceptable to use
HCI_ERROR_UNSPECIFIED directly. That said, the patch will look like this:

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index f75ef12f1..73c120258 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1102,8 +1102,10 @@ static void hci_conn_unlink(struct hci_conn *conn)
 			 */
 			if ((child->type == SCO_LINK ||
 			     child->type == ESCO_LINK) &&
-			    child->handle == HCI_CONN_HANDLE_UNSET)
+			    child->handle == HCI_CONN_HANDLE_UNSET) {
+				hci_connect_cfm(child, HCI_ERROR_UNSPECIFIED);
 				hci_conn_del(child);
+			}
 		}
 
 		return;

Also, while this fix can semantically be applied to v6.1 and above, an explicit
backport is required due to the hci_conn_unlink refactoring in the mainline.

Thanks,
Ruihan Li