Received: by 2002:a05:7412:3b8b:b0:fc:a2b0:25d7 with SMTP id nd11csp892668rdb; Fri, 9 Feb 2024 04:37:34 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCW9glQJQaejCAE4ST14ci4GkzTrwEqPwwymVqMhC3iyERNbJAQcnkmAa8NvktnbEu1jsasV7lb7N65FnmS33JVWmYlw4Mei5ENZSaKoOg== X-Google-Smtp-Source: AGHT+IEpvWhY4liDTzzDeaSMCSyEBy9X/LozLfZheKaBgp0Vpvi/83dABhs/pv72zucPfxlyjpWj X-Received: by 2002:a05:622a:1048:b0:42b:f47c:ad09 with SMTP id f8-20020a05622a104800b0042bf47cad09mr1608435qte.16.1707482254709; Fri, 09 Feb 2024 04:37:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707482254; cv=pass; d=google.com; s=arc-20160816; b=yh1z+Yhw8o2FrySQAUhIYINjutPcuXDsmkLeeA4KTmiypjjZzpzSvYSCkQ0Gok/YBv 1cGGhGVTqJd2Jqnb+lsZwLI2J9odhFEm1sTEFIzvoFWwn9hUM2WkKP249VL5HcPqRzdI xUX9+1KGwjhSOUCaQhsRizoXx4qnkyT5bEeVigbHWVcfuVi9gaTuP2G69fJsrdspyHl+ W6Ohdm6nH16Imu8zpEb+TVwfluztRzwpFRIM+iMdWICv7GoTd3LrIC6a9VCSOwc2WTbC ResXtXsryrHoNlY2RrLJ2Z3vvBraR18+WwpWXWXv/3KfkJDLjotKqxBCfpQ2EnSj6K0N yIDA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:cc:content-language :references:to:subject:from:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=cOMDdzD2bzyDj0wza7P8DnHW6+Brce1MJJMoLD6gKYo=; fh=ZZRZrDVo5f350Xg7TsQ/VVa801niieWn/3SM3F22LfU=; b=GW9/iPoQMI10v3f+0qsq7Y2iW6sSPuuuFJnDIJRKIVWs8nJPeFoxIETAQXEgB/6Ial Nl7yIbth+V+d0p8mufH55SqfOL2ThCsa/xR2OhiCwIS6hxFkd3MPkyX7jiVu6gQU3XjP Rw/WKxXP0D+JkUSGcKJL4tFCvZX2caPGAh40kgDJw10fjn+wFicTXs0SLSixaJvB4W/3 NuZ0IOjZCxQ0UQ5Bw/Rb3K9QXZvCVFc9xn4z0EDpq+/HxS7QtPuwFQaC3l/+V80VUjTh LtI3XTUCeHA0T55ZhNaQ1VzeEC+cYjT8lmqLI3H7/Y1cKmfmAWYJHCH0BSm3jQ+CMfPV 5w3g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=v0yd.nl); spf=pass (google.com: domain of linux-bluetooth+bounces-1707-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-bluetooth+bounces-1707-linux.lists.archive=gmail.com@vger.kernel.org" X-Forwarded-Encrypted: i=2; AJvYcCWMObJji1Ig5isQd9c8RC4cDWxXox+fQVMeojZGzyJInZu6szgZRR2guW1ixEOSZ0+16WhwI9C9jOeDuyh5BojE+QhLtcsb3SdnPKS3ww== Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id s19-20020ac85cd3000000b0042c50e9973fsi1681708qta.722.2024.02.09.04.37.34 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 04:37:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-1707-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=v0yd.nl); spf=pass (google.com: domain of linux-bluetooth+bounces-1707-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-bluetooth+bounces-1707-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 78B8D1C217CA for ; Fri, 9 Feb 2024 12:37:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B03C1374DD; Fri, 9 Feb 2024 12:37:20 +0000 (UTC) X-Original-To: linux-bluetooth@vger.kernel.org Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E174528DD3; Fri, 9 Feb 2024 12:37:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707482240; cv=none; b=L41mXjcog2p/7uzvSqa6kEWNKz8krzL+7+PSbGNNc8JK2+tr5Ihv+kfr9xaEKkvQoBipR1BC1owA8Gib9lw5qnGqh3bvfFjQx9+4F7O36Wvq+LXyRbs56NcE6zxUsNd+f9DLdEg4rO9Z+UnZIKzgjrPa+VA7TxDDduQmXS+PgSM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707482240; c=relaxed/simple; bh=VNK68ZcMYzwD13qMNJ6bgFbcgemY4GsDe2xDQ6kje9c=; h=Message-ID:Date:MIME-Version:From:Subject:To:References:Cc: In-Reply-To:Content-Type; b=Jg5WS+Ica32Dbj1gJL/Gz50btpWTliV2VMNsfHaG6WG6p63n6UykwVua/DUm3JeD1449dsua8m+47pkhLBhJOG8IL/q4WS8jieR2jvNcC3KBuzedHvE5mWvEF77Lau282gvtdup2tN2ZppUx7qRpveXpaJ75eLL8mzFK/wScAiU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=v0yd.nl; spf=pass smtp.mailfrom=v0yd.nl; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=v0yd.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=v0yd.nl Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4TWYJg4YCcz9sWY; Fri, 9 Feb 2024 13:37:07 +0100 (CET) Message-ID: <216c95d9-db1f-487a-bf3d-17a496422485@v0yd.nl> Date: Fri, 9 Feb 2024 13:37:02 +0100 Precedence: bulk X-Mailing-List: linux-bluetooth@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: =?UTF-8?Q?Jonas_Dre=C3=9Fler?= Subject: Re: [syzbot] [bluetooth?] KASAN: slab-use-after-free Write in __hci_acl_create_connection_sync To: syzbot , davem@davemloft.net, edumazet@google.com, johan.hedberg@gmail.com, kuba@kernel.org, linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org, luiz.dentz@gmail.com, luiz.von.dentz@intel.com, marcel@holtmann.org, netdev@vger.kernel.org, pabeni@redhat.com, syzkaller-bugs@googlegroups.com References: <0000000000007cea730610e083e8@google.com> Content-Language: en-US Cc: verdre@v0yd.nl In-Reply-To: <0000000000007cea730610e083e8@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi everyone! On 08.02.24 16:32, syzbot wrote: > syzbot has bisected this issue to: > > commit 456561ba8e495e9320c1f304bf1cd3d1043cbe7b > Author: Jonas Dreßler > Date: Tue Feb 6 11:08:13 2024 +0000 > > Bluetooth: hci_conn: Only do ACL connections sequentially > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=154f8550180000 > start commit: b1d3a0e70c38 Add linux-next specific files for 20240208 > git tree: linux-next > final oops: https://syzkaller.appspot.com/x/report.txt?x=174f8550180000 > console output: https://syzkaller.appspot.com/x/log.txt?x=134f8550180000 > kernel config: https://syzkaller.appspot.com/x/.config?x=bb693ba195662a06 > dashboard link: https://syzkaller.appspot.com/bug?extid=3f0a39be7a2035700868 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11d95147e80000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=107c2d8fe80000 > > Reported-by: syzbot+3f0a39be7a2035700868@syzkaller.appspotmail.com > Fixes: 456561ba8e49 ("Bluetooth: hci_conn: Only do ACL connections sequentially") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection Hmm, looking at the backtraces, I think the issue that the introduction of the sequential connect has introduced another async case: In hci_connect_acl(), when we call hci_acl_create_connection_sync(), the conn state no longer immediately gets set to BT_CONNECT, but remains in BT_OPEN or BT_CLOSED until the hci_sync queue actually executes __hci_acl_create_connection_sync(). This means that now hci_connect_acl() is happy to do multiple hci_acl_create_connection_sync calls, and the hci_sync machinery will happily execute them right after each other. Then the newly introduced hci_abort_conn_sync() in __hci_acl_create_connection_sync() calls hci_conn_del() and frees the conn object, so the second time we enter __hci_acl_create_connection_sync(), things blow up. It looks to me like in theory the hci_connect_le_sync() logic is prone to a similar issue, but in practice that's prohibited because in hci_connect_le_sync() we lookup whether the conn object still exists and bail out if it doesn't. Even for LE though I think we can queue multiple hci_connect_le_sync() calls and those will happily send HCI_OP_LE_CREATE_CONN no matter what the connection state actually is? So assuming this analysis is correct, what do we do to fix this? It seems to me that 1) we want a BT_CONNECT_QUEUED state for connections, so that the state machine covers this additional stage that we have for ACL and LE connections now. 2) the conn object can still disappear while the __hci_acl_create_connection_sync() is queued, so we need something like the "if conn doesn't exist anymore, bail out" check from hci_connect_le_sync() in __hci_acl_create_connection_sync(), too. That said, the current check in hci_connect_le_sync() that's using the connection handle to lookup the conn does not seem great, aren't these handles re-used after connections are torn down? Cheers, Jonas