netdev - Re: [syzbot] [bluetooth?] KASAN: slab-use-after-free Write in sco_chan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 16 May 2023 00:01:19 +0800
From: Ruihan Li <lrh2000@....edu.cn>
To: linux-bluetooth@...r.kernel.org,
	luiz.dentz@...il.com,
	johan.hedberg@...il.com,
	marcel@...tmann.org
Cc: syzbot+cf54c1da6574b6c1b049@...kaller.appspotmail.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	syzkaller-bugs@...glegroups.com,
	Ruihan Li <lrh2000@....edu.cn>
Subject: Re: [syzbot] [bluetooth?] KASAN: slab-use-after-free Write in sco_chan_del

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