From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=79.135.106.26 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794308591; b=cuTGJJjCFgoO+QWZhP9L16tzclfKQqHkWUVFSaknIJ/UWCM5T17sdSyr870m6aXfXdJr 80Ec4/R15mJIJ1wGfgEqG8PLQ+KQ/bJE3aVpHZNUkW6No03HL9P5gjTTiYeFUIDzsDC+9 uXOXC7Qjfymiwd6P0QxxFM8zMA719pcslUxXKkE35NV+gaUIAhFnrBez30bq7Z1qRCojI ongIqRSlp/ktszV27u4FV7w/KSYhqLw6Sj/NvNJuO4OG8CSGR7mmVrIOVbJjneRAVknPK /vrw9/lB/NFBA7VHHZl9Ip8HIJtxEiyZaNz+dQGms/L3aEpB+Qpm/XCLezlV8B4o2sA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794308591; h=DMARC-Filter:DKIM-Signature:Date:To:From:Cc:Subject:Message-ID: In-Reply-To:References:Feedback-ID:X-Pm-Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=BZRqNPkVHbDtKON6wv6OQaO7er0kYUMxGcWb88xBRWU=; b=pwXBH/DGrbcbCXzyNxvdNDA9H8smmT/Vg15kOzoVZ3IiOert7tJ8rlJSu8aQW4O1nHus 1/dWwRcHFSLAEp2GZrAgE7c70zt6cYFnETsXJ43G7qIN09oOPdFOrh3TyoS/kpQhi1IzG mO3POfkkh7o7XBhxy6pjE2y02tprSYiCoPJSNtzpm0eTiMY+kHzh8i+uP/HTpqvDntbgx lXelib6jzi8VjgZEzocdi2b/bL1ONt54/tNxPWEgyrmQZkX0PmlklYt3BvRRf2Xi97q3r 5IWYh2GQtLgPkJNgf8vFTZykGHnlhubk3TTvOmzrEJ8zbxOB9+jRqC4w4F91Q6G9giA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=modelmiser.com; spf=pass smtp.mailfrom=modelmiser.com; dkim=pass header.d=modelmiser.com header.i=@modelmiser.com header.a=rsa-sha256 header.s=protonmail header.b=Wf3JovIS; arc=none smtp.remote-ip=79.135.106.26 Received: from mail-10626.protonmail.ch (mail-10626.protonmail.ch [79.135.106.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EF07606A321 for ; Tue, 10 Nov 2026 11:03:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 6EF07606A321 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=modelmiser.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=modelmiser.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=modelmiser.com header.i=@modelmiser.com header.a=rsa-sha256 header.s=protonmail header.b=Wf3JovIS DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=modelmiser.com; s=protonmail; t=1794308588; x=1794567788; bh=BZRqNPkVHbDtKON6wv6OQaO7er0kYUMxGcWb88xBRWU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Wf3JovISJQKvxIHhu4gnnOUOlHwAjFvXnojjbYOeSYw01J5lrYINFyJ+RxZ2KD1OC k2YkS30LrYMAIWavXGmgHc9cz2HsIyG/zE9d9KI1qFGaKD+1YPBfEkpAD3FoLMu71p aUgE7KtGlriELzcJMLE2tuwxwBrzrfTJOKMDFSE2IpSkJzud18e2+UVmQVgYDZRN/L G7JcMBTbxM5V9usJrC4weOlRyErtjCD6YWvHhj7Ciev3LtvdMJ9ry0k5xZ7ejoihp0 zbTVa4wTEWVD190XyKFEm6yU1Jha9hUR2DlxR6RDOmFCnn1roHFMYfGAvRRbJehZSz 6Ss0tkRHhxQzA== Date: Tue, 10 Nov 2026 11:03:01 +0000 To: Cen Zhang , Marcel Holtmann , Luiz Augusto von Dentz From: Chad Aldreda Cc: linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, jjzuming@gmail.com Subject: Re: [PATCH] Bluetooth: vhci: Flush suspend work after removing debugfs Message-ID: <20261110110253.1118214-2-ca@modelmiser.com> In-Reply-To: References: Feedback-ID: 232753253:user:proton X-Pm-Message-ID: d83fc3b1e44738560cbe08a5fe327f6227997fd9 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, 25 Oct 2026, Cen Zhang wrote: > Runtime testing of this change was not performed. The use-after-free in your report reproduces on mainline with the two test-only delays below, and your patch removes it. Tested on mainline d48723711bae (v7.4-rc1-672), whose hci_vhci.c and hci_sync.c match bluetooth-next at 983f3fcb1282 (hci_core.c differs only in rfkill handling), on x86_64 in QEMU (4 vCPUs) with KASAN, lockdep, DEBUG_LIST, kmemleak and hung-task detection. A test program opens /dev/vhci, answers every HCI command with a Command Complete, brings the controller up with HCIDEVUP, then closes /dev/vhci while another thread keeps toggling force_suspend in debugfs. One mode keeps answering commands until close() returns; the other stops answering before close(). Unaided the window is too narrow: 300 cycles in the answering mode on the unpatched kernel gave no reports. Both kernels therefore carried two test-only delays, not for merging: vhci_release(): =09cancel_delayed_work_sync(&data->open_timeout); =09flush_work(&data->suspend_work); +=09msleep(50); hci_suspend_dev(): =09hci_req_sync_unlock(hdev); +=09msleep(200); =09hci_clear_wake_reason(hdev); With the delays and without your patch, 30 cycles in each mode gave 834 and 621 KASAN reports (kasan_multi_shot, so one bad close gives many). Two objects are hit. The hci_dev is accessed after free from hci_suspend_dev(), including the __mutex_lock() site in your report; it is page-backed, so KASAN shows no free stack, and once the page is reused the same accesses show up as slab-out-of-bounds against unrelated slab objects. The vhci_data (kmalloc in vhci_open(), kfree in vhci_release()) is read by vhci_suspend_work() and read and written by process_one_work() after free, because suspend_work is embedded in it. hci_resume_dev() was also reached, with an hdev pointer read from the freed vhci_data, so it dereferenced an unrelated address. With the delays and your patch, 160 cycles (130 answering, 30 not) had no KASAN, lockdep, DEBUG_LIST, kmemleak or hung-task reports. Without the delays, 150 cycles with the patch (answering mode) were also clean; since the unpatched kernel was clean without them too, that run only shows no regression. As expected, release can now also wait for suspend or resume work that is already running, including an HCI command timeout inside it, as the existing first flush_work() already can. Not tested: suspend with force_wakeup set, with connections, or with scanning, advertising or discovery active (the controller was brought up with HCIDEVUP and no bluetoothd, so hci_suspend_sync() had nothing to pause), mgmt, real controllers or btvirt, module unload (Bluetooth was built in), other architectures, and a build of bluetooth-next itself (compared at source level only). The harness and this report were produced with an AI assistant (Claude Opus 5.5), which also did the earlier runs, including the unpatched comparison. I ran the final version on the patched kernel myself and got the same results. The harness is available on request. Tested-by: Chad Aldreda