[PW_SID:1163440] [v3] Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex

[BluezTestBot]

An RFCOMM connect() issued while a BR/EDR link is being authenticated
makes lockdep report a circular dependency, and the reported cycle is a
real AB/BA between rfcomm_mutex and hdev->lock.

rfcomm_security_cfm() is called from the HCI event path, which already
holds hdev->lock:

hci_rx_work()
hci_event_packet()
hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]

while an RFCOMM connect() from userspace takes the same two locks the
other way round:

rfcomm_sock_connect()
rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open()
rfcomm_session_create()
kernel_connect()
l2cap_sock_connect()
l2cap_chan_connect() [hdev->lock]

WARNING: possible circular locking dependency detected
kworker/u131:1/1128 is trying to acquire lock:
rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
but task is already holding lock:
hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0
Chain exists of:
rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock

hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback
the same way.

Both orders have to be seen in the same boot, which is why a BR/EDR
connection alone is not enough to show it: a session set up by the
remote side is created by rfcomm_accept_connection() in krfcommd, which
calls kernel_accept() and never takes hdev->lock under rfcomm_mutex.
Connecting a device that authenticates and encrypts the link and then
calling connect() on an RFCOMM socket towards any address - the connect
does not have to succeed, the order is recorded before the page timeout

• reports it every time.

Only the session socket has to be connected with the lock held, and it
does not: nothing else can see the socket before it is put on the
session list. So connect it first and take rfcomm_mutex afterwards,
which removes the rfcomm_mutex -> hdev->lock order for good, rather
than keeping the HCI event path out of rfcomm_mutex.

rfcomm_session_create() becomes rfcomm_session_connect(), which returns
the connected socket without touching the session list, and
rfcomm_dlc_open() adds the session once it holds the lock again. If
another opener added a session for the same pair while this socket was
connecting, that session is used and this socket is dropped.
__rfcomm_dlc_open() now takes the session it should use, and its state
check runs after the lock is re-acquired, so a DLC that was opened or
closed in the meantime is still handled.

Over an existing ACL link the connection can complete before the
session reaches the list, and the wakeup from the socket callback is
then lost, so krfcommd is woken once the session is visible.

Fixes: 759c185 ("Bluetooth: RFCOMM: serialize security confirmation handling")
Suggested-by: Pauli Virtanen pav@iki.fi
Reported-by: Pauli Virtanen pav@iki.fi
Closes: https://lore.kernel.org/linux-bluetooth/5e76a95e934e451e7006db28827c2d64af5a88be.camel@iki.fi/
Reported-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-bluetooth/6a92fadc.08e933ee.dbf97.008f.GAE@google.com/
Cc: stable@vger.kernel.org
Signed-off-by: Mikhail Gavrilov mikhail.v.gavrilov@gmail.com

The commit this fixes is in v7.3-rc1 and is marked for stable, so this
probably wants the bluetooth fixes tree rather than -next.

v1: https://lore.kernel.org/linux-bluetooth/20260902235132.453044-1-mikhail.v.gavrilov@gmail.com/
v2: https://lore.kernel.org/linux-bluetooth/20260904012028.77590-1-mikhail.v.gavrilov@gmail.com/

v3:

• fix the lock order on the connect side instead of deferring the
  security confirmation, as asked for on v2; rfcomm_security_cfm()
  and krfcommd are left alone, so none of the questions about delayed
  confirmations apply any more
• the queue, its annotations and the flush from v2 are gone

Tested on 7.3.0-rc2 with an MT7922 controller (btusb). Without the
patch the reproducer below reports the inversion on every run; with it
applied it stays quiet and the validator is still armed afterwards
(debug_locks: 1). A 10 hour session with BR/EDR headset connects,
AVRCP and SCO traffic produced no lockdep report either.

An outgoing connect towards a connected headset is answered in 29 ms
with ECONNREFUSED - the session is established over the existing ACL
link and the peer rejects the channel - which is the case where the
L2CAP connect can complete before the session reaches the list.
Towards an idle device the same connect fails with EHOSTDOWN after the
page timeout.

The connect() side used for the reproducer, so that it does not depend
on which end sets up the HFP session:

#include <stdint.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>

#define BTPROTO_RFCOMM 3

struct sockaddr_rc {
unsigned short rc_family;
uint8_t rc_bdaddr[6]; /* little endian */
uint8_t rc_channel;
};

int main(void)
{
struct sockaddr_rc addr = { .rc_family = AF_BLUETOOTH,
.rc_channel = 1 };
int fd = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);

  memcpy(addr.rc_bdaddr, "\x55\x44\x33\x22\x11\x00", 6);
  connect(fd, (struct sockaddr *)&addr, sizeof(addr));
  close(fd);
  return 0;

}

net/bluetooth/rfcomm/core.c | 114 ++++++++++++++++++++++++------------
1 file changed, 76 insertions(+), 38 deletions(-)

[github-actions]

CheckPatch
Desc: Run checkpatch.pl script
Duration: 0.69 seconds
Result: PASS

[github-actions]

VerifyFixes
Desc: Verify Fixes tag format and validity
Duration: 0.12 seconds
Result: PASS

[github-actions]

VerifySignedoff
Desc: Verify Signed-off-by chain
Duration: 0.12 seconds
Result: PASS

[github-actions]

GitLint
Desc: Run gitlint
Duration: 0.30 seconds
Result: PASS

[github-actions]

SubjectPrefix
Desc: Check subject contains "Bluetooth" prefix
Duration: 0.11 seconds
Result: PASS

[github-actions]

BuildKernel
Desc: Build Kernel for Bluetooth
Duration: 21.74 seconds
Result: PASS

[github-actions]

CheckAllWarning
Desc: Run linux kernel with all warning enabled
Duration: 25.39 seconds
Result: PASS

[github-actions]

CheckSparse
Desc: Run sparse tool with linux kernel
Duration: 27.72 seconds
Result: PASS

[github-actions]

BuildKernel32
Desc: Build 32bit Kernel for Bluetooth
Duration: 22.46 seconds
Result: PASS

[github-actions]

CheckKernelLLVM
Desc: Build kernel with LLVM + context analysis
Duration: 26.39 seconds
Result: PASS

[github-actions]

TestRunnerSetup
Desc: Setup kernel and bluez for test-runner
Duration: 574.84 seconds
Result: PASS

[github-actions]

TestRunner_rfcomm-tester
Desc: Run rfcomm-tester with test-runner
Duration: 13.19 seconds
Result: PASS

[github-actions]

IncrementalBuild
Desc: Incremental build with the patches in the series
Duration: 21.86 seconds
Result: PASS