From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B87C626F289 for ; Sun, 26 Jul 2026 13:38:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785073089; cv=none; b=oCnffcAkgg8ukMFntYB9HyjKJuUNdpFs12sFR6qT0eJbeuGsf93UaxMyXUm5dYXs1i8spDpPxaK5CRPBEkgOCNZSHckRk9AKXkRzCmH5ho7N07G+EfQUCWTWXJ0+V48GRPglsOCz+mXWBhCJ0nL8ki7AXNctJJWI8DOM+0kwBFU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785073089; c=relaxed/simple; bh=NCIHeDIA/4OImcgoZmMiczVVh4u0wDhubbPjsAOYTGs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L92U957qCaHYmIJlEy4kfMgZiXrVLdHsJoAikdFnr2AVxcXnbM1T0eghUvNy7uKcfmKcaXMpGfpImNNexNiLBXgEZ+s/4ZInhQTl7a72kiu2iA4HKlIDlU8E/O5AWAtQrmMG3M3R8P+vLiEf46Emy+6u5HDfnXO3/MpS0Q4nki8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OhnO3xQu; arc=none smtp.client-ip=209.85.216.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OhnO3xQu" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-38ec1402b05so1386933a91.2 for ; Sun, 26 Jul 2026 06:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785073088; x=1785677888; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=jysWq3C3ThJMdK6hdhgg2VKXM1RyHpRSI8wbIXfJEBQ=; b=OhnO3xQuNdqSujl0XWl66eTW9UCsMiwo9BpnV7qEdSh7OI16dnS46i2Y9nNb0Pdsxc lwiNbQ8Sl2tpwMZ23xSL0gC8gieMkzv2wlbFgY3ehy3kgtN8O1qMegdJxP815KjgDUKA Su/iM4f9zCBxZWauu2tkTqijtcC6aw9F6vU9fl/co8kyDfTq9h7qF65oN+So8+1dTRJQ MN3B9KaOoOvf2wTRNJrXF9mgD+UwKBTcmgWdLkrU1GGaYtzTByG4TN3bht0KVL1maUsU 5zRhrTFISXogodbfOqNBY1vWGFOdPSX2Ef7sdNyYrj4ilnkDWU3tkPJjlSMiCZ4eQYX9 Eu4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785073088; x=1785677888; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=jysWq3C3ThJMdK6hdhgg2VKXM1RyHpRSI8wbIXfJEBQ=; b=HtK8e+QGHueyFEmgTEDPB+Fq9OPrs60iUQBC4d8lrcgov1WNwVBLoVPF5b0BceMXgt EDMEyZpsX2eL0YfJrloiu4+HSV6v6b4zlr+ih0sw80N+a9+jnvRU+NFOOwXc/zIQAPnb 1g5K8uRfKZ1eAEafVcioZHazWx0v6LuXA+h5ooNdgZL1rJZUDma9Mt+4n0kos+Uv77th VXzbsNwtoQzAVVd37nNos7wNZ1Tw6JXwjvLY4S8/DovDhOxfZoOfddyqaT4hLSRl83cM xG6K54OEoVyO7hlOhRlJcMVXhyb9mO5Rua6Aq0AkA0rJZxcW9NPpAYQbyop0EeajI20g senQ== X-Forwarded-Encrypted: i=1; AHgh+RpGcWovNbzJb6mb8Uj0TD75izi79Bz2J3HWDUiYoq6EfwUwovFFTMh6cVPaZFWQYcEckmt8EMhQIOaA57s=@vger.kernel.org X-Gm-Message-State: AOJu0Yxi3Gh8OhhwN+achZQhYdXyEBGdHt3tJfKikwCV0+hCUrCIVfg8 CJM60hasYDlMMd3Bw/z1VrGGxU9AqQLxDvCaPfPgK4lJpcdKersdDZM9 X-Gm-Gg: AR+sD10jJB49HLgvBbark6mri5ZH4FrttwiG5/fzVxwCoaEuo2+5/C4uWnSo2MtbH27 X+MlXB7mXp1OANK87ScryddS3atixGIq7eXqvKXyCXTXh4JtyiV1hUy1bqtqQiWssST4OcX3sPR Vg8uh+Llzd8zgYd21+mwAa1ggF4VQqj0hP/HeNmN5Pf0Cj3D+91E1w4tn5dHgNmmIHdLuQ2fIYq bTGqvL8sMI77fimcwjx+jFaOfhtzvDnXlm6QR38PuenTqRAno/64uRi6p73OGXUkMJItmVRxMQV 3hWDdcCHqQbXwNU+KXqFxXsJ8DtRM9xo5zFBbZ7Mw8TCgjTzZNxjOVdEIR6r/2QAooTuEwYVbO5 Mu/M0tFj/njKPzEWFFw0G9GMEFCGHLCkHdlfEVZNchVbkOoV5oyJuX9MI2wJWno1yF9PWIQ== X-Received: by 2002:a17:90b:3b41:b0:381:25ce:bcc2 with SMTP id 98e67ed59e1d1-38f293cd1b0mr5348250a91.6.1785073087936; Sun, 26 Jul 2026 06:38:07 -0700 (PDT) Received: from beelink.. ([186.22.57.86]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13e53094d65sm15280380c88.13.2026.07.26.06.38.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Jul 2026 06:38:07 -0700 (PDT) From: Aldo Ariel Panzardo To: Baul Lee , Pauli Virtanen Cc: Aldo Ariel Panzardo , Federico Kirschbaum , Luiz Augusto von Dentz , marcel@holtmann.org, linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Bluetooth: SCO: fix sco_conn double free on outgoing connect Date: Sun, 26 Jul 2026 10:37:40 -0300 Message-ID: <20260726133748.437733-1-qwe.aldo@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <5e2a239a419898c87e80ed360b06e287225de00a.camel@iki.fi> References: <20260726055431.42350-1-baul.lee@xbow.com> <5e2a239a419898c87e80ed360b06e287225de00a.camel@iki.fi> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Pauli, Baul, Federico, Thanks for looking at both patches side by side. To connect the threads: the "only socket owns sco_conn" approach you pointed to is my v3 https://lore.kernel.org/linux-bluetooth/20260725195230.967546-1-qwe.aldo@gmail.com/ which is on the list and passed sco-tester in CI. I found and root-caused this independently and posted the first public fix on 2026-07-23 (v1), with a /dev/vhci KASAN reproducer that races close() of an SCO socket against an injected Disconnection Complete. I see from Baul's patch that XBOW reported the same issue privately on 2026-07-10 -- I'm happy for that earlier report to be credited (Reported-by, or however you and they prefer); I don't want to step on it. On the substance I agree the sco_data access needs serializing, and this is the residual UAF I already flagged when I sent v3: with the over-put fixed, sco_recv_scodata() still reads hcon->sco_data under hci_dev_lock and sco_conn_hold_unless_zero()s it, but the clear in sco_conn_free() is not under that lock, so the read can land on an already-freed sco_conn: BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730 I'll send the serialization as a follow-up on top of v3, along the lines you sketched: clear hcon->sco_data in sco_conn_del() under hdev->lock so the field can carry a __guarded_by(&hdev->lock) annotation, and -- to avoid the "SCO Disconnect - Success" regression you spotted in the other patch -- give the socket its own hci_conn reference that it drops on close(), so closing still tears the link down while the sco_conn keeps a single association reference cleared under the lock in sco_conn_del(). I'll only post it once the reproducer is clean under KASAN and sco-tester passes. Thanks, Aldo