Re: [PATCH] Bluetooth: SCO: fix race conditions in sco_sock_connect()

[Cen Zhang]

Hi Luiz,

> Ok, the first and the second points don't seem to agree. If each
> thread creates its own socket then the sk wouldn't be the same would
> it? Or is the first point about two concurrent connect syscalls to the
> same fd? In which case that should have been made clearer.
>

Thank you for pointing this out. You are right -- the original
description was not clear enough. This is indeed about two concurrent
connect() syscalls on the same socket fd.

I have rewritten the commit message with a detailed timing diagram
that reflects the actual scenario I confirmed with logging
instrumentation. The race requires three participants:

1. Thread A calls connect() and completes sco_connect() under
   hci_dev_lock, setting sk_state = BT_CONNECT.

2. Thread B also called connect() on the same fd and passed the
   sk_state check (without lock_sock), but is blocked on
   hci_dev_lock inside sco_connect().

3. While Thread B is blocked, Thread A's HCI connection
   disconnects. sco_conn_del() runs under hci_dev_lock,
   clears the socket (sk_state = BT_CLOSED, SOCK_ZAPPED),
   and releases hci_dev_lock.

4. Thread B unblocks, creates a new HCI connection and
   sco_conn, and successfully attaches it to the already-closed
   socket -- reviving a zombie socket from BT_CLOSED back to
   BT_CONNECT, leading to use-after-free on subsequent cleanup.

Best regards,
Cen