Re: [PATCH] Bluetooth: SCO: fix sco_conn double free on outgoing connect

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/[email protected]/

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