From: Aldo Ariel Panzardo <qwe.aldo@gmail.com>
To: Baul Lee <baul.lee@xbow.com>, Pauli Virtanen <pav@iki.fi>
Cc: Aldo Ariel Panzardo <qwe.aldo@gmail.com>,
Federico Kirschbaum <federico.kirschbaum@xbow.com>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
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 [thread overview]
Message-ID: <20260726133748.437733-1-qwe.aldo@gmail.com> (raw)
In-Reply-To: <5e2a239a419898c87e80ed360b06e287225de00a.camel@iki.fi>
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
prev parent reply other threads:[~2026-07-26 13:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 5:54 [PATCH] Bluetooth: SCO: fix sco_conn double free on outgoing connect Baul Lee
2026-07-26 9:55 ` bluez.test.bot
2026-07-26 10:15 ` [PATCH] " Pauli Virtanen
2026-07-26 13:37 ` Aldo Ariel Panzardo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260726133748.437733-1-qwe.aldo@gmail.com \
--to=qwe.aldo@gmail.com \
--cc=baul.lee@xbow.com \
--cc=federico.kirschbaum@xbow.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=pav@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox