* [syzbot] [bluetooth?] possible deadlock in rfcomm_security_cfm
@ 2026-08-29 15:29 syzbot
2026-09-20 16:08 ` syzbot
2026-09-21 6:23 ` Forwarded: [PATCH v3] Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex syzbot
0 siblings, 2 replies; 3+ messages in thread
From: syzbot @ 2026-08-29 15:29 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, luiz.dentz, marcel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: cf72cbb39da8 Merge tag 'io_uring-7.3-20260828' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11b8ae25580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=74071deb72339c215b2e
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/7684a30c51dd/disk-cf72cbb3.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4f401bdb1bb3/vmlinux-cf72cbb3.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4379cea44543/bzImage-cf72cbb3.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Tainted: G L
------------------------------------------------------
kworker/u9:2/5598 is trying to acquire lock:
ffffffff90f7e040 (rfcomm_mutex){+.+.}-{4:4}, at: rfcomm_security_cfm+0x3f/0x4b0 net/bluetooth/rfcomm/core.c:2222
but task is already holding lock:
ffffffff90f51500 (hci_cb_list_lock){+.+.}-{4:4}, at: hci_encrypt_cfm+0x11b/0x740 include/net/bluetooth/hci_core.h:2239
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (hci_cb_list_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
hci_connect_cfm include/net/bluetooth/hci_core.h:2163 [inline]
hci_remote_features_evt+0x485/0x9b0 net/bluetooth/hci_event.c:3786
hci_event_func net/bluetooth/hci_event.c:7887 [inline]
hci_event_packet+0x8e9/0xcd0 net/bluetooth/hci_event.c:7938
hci_rx_work+0x451/0xfc0 net/bluetooth/hci_core.c:4041
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #1 (&hdev->lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
l2cap_chan_connect+0xac/0x2050 net/bluetooth/l2cap_core.c:7266
l2cap_sock_connect+0x37a/0x770 net/bluetooth/l2cap_sock.c:255
kernel_connect+0x107/0x160 net/socket.c:3755
rfcomm_session_create net/bluetooth/rfcomm/core.c:808 [inline]
__rfcomm_dlc_open net/bluetooth/rfcomm/core.c:385 [inline]
rfcomm_dlc_open+0x838/0xac0 net/bluetooth/rfcomm/core.c:428
rfcomm_sock_connect+0x42c/0x690 net/bluetooth/rfcomm/sock.c:421
connect_socket net/socket.c:2141 [inline]
connect_socket net/socket.c:2131 [inline]
__sys_connect_file+0x146/0x1a0 net/socket.c:2166
__sys_connect+0x141/0x170 net/socket.c:2183
__do_sys_connect net/socket.c:2189 [inline]
__se_sys_connect net/socket.c:2186 [inline]
__x64_sys_connect+0x72/0xb0 net/socket.c:2186
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (rfcomm_mutex){+.+.}-{4:4}:
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5254
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
rfcomm_security_cfm+0x3f/0x4b0 net/bluetooth/rfcomm/core.c:2222
hci_encrypt_cfm+0x18e/0x740 include/net/bluetooth/hci_core.h:2242
hci_encrypt_change_evt+0x3e1/0xfb0 net/bluetooth/hci_event.c:3715
hci_event_func net/bluetooth/hci_event.c:7887 [inline]
hci_event_packet+0x8e9/0xcd0 net/bluetooth/hci_event.c:7938
hci_rx_work+0x451/0xfc0 net/bluetooth/hci_core.c:4041
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(hci_cb_list_lock);
lock(&hdev->lock);
lock(hci_cb_list_lock);
lock(rfcomm_mutex);
*** DEADLOCK ***
locks held by kworker/u9:2/5598: 4, last CPU#0:
#0: ffff88802e39e940 ((wq_completion)hci3#2){+.+.}-{0:0}, at: process_one_work+0x1466/0x1b10 kernel/workqueue.c:3362
#1: ffffc9000250fd08 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_one_work+0xa2c/0x1b10 kernel/workqueue.c:3363
#2: ffff88807d7b80b8 (&hdev->lock){+.+.}-{4:4}, at: hci_encrypt_change_evt+0x83/0xfb0 net/bluetooth/hci_event.c:3627
#3: ffffffff90f51500 (hci_cb_list_lock){+.+.}-{4:4}, at: hci_encrypt_cfm+0x11b/0x740 include/net/bluetooth/hci_core.h:2239
stack backtrace:
CPU: 0 UID: 0 PID: 5598 Comm: kworker/u9:2 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/16/2026
Workqueue: hci3 hci_rx_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_circular_bug.cold+0x178/0x1be kernel/locking/lockdep.c:2059
check_noncircular+0x146/0x160 kernel/locking/lockdep.c:2191
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5254
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
rfcomm_security_cfm+0x3f/0x4b0 net/bluetooth/rfcomm/core.c:2222
hci_encrypt_cfm+0x18e/0x740 include/net/bluetooth/hci_core.h:2242
hci_encrypt_change_evt+0x3e1/0xfb0 net/bluetooth/hci_event.c:3715
hci_event_func net/bluetooth/hci_event.c:7887 [inline]
hci_event_packet+0x8e9/0xcd0 net/bluetooth/hci_event.c:7938
hci_rx_work+0x451/0xfc0 net/bluetooth/hci_core.c:4041
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [syzbot] [bluetooth?] possible deadlock in rfcomm_security_cfm
2026-08-29 15:29 [syzbot] [bluetooth?] possible deadlock in rfcomm_security_cfm syzbot
@ 2026-09-20 16:08 ` syzbot
2026-09-21 6:23 ` Forwarded: [PATCH v3] Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex syzbot
1 sibling, 0 replies; 3+ messages in thread
From: syzbot @ 2026-09-20 16:08 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, luiz.dentz, marcel,
mikhail.v.gavrilov, nicoyip.dev, pav, syzkaller-bugs
syzbot has found a reproducer for the following issue on:
HEAD commit: 518e5b794c06 Merge tag 'for-7.3-rc3-tag' of git://git.kern..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=137ba4c9580000
kernel config: https://syzkaller.appspot.com/x/.config?x=84649d3ff8d550cb
dashboard link: https://syzkaller.appspot.com/bug?extid=74071deb72339c215b2e
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14809525580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=161a3ff9580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/1e68973061b3/disk-518e5b79.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4a77cf97afca/vmlinux-518e5b79.xz
kernel image: https://storage.googleapis.com/syzbot-assets/70ecbc754c60/bzImage-518e5b79.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kworker/u9:1/4919 is trying to acquire lock:
ffffffff90f828c0 (rfcomm_mutex){+.+.}-{4:4}, at: rfcomm_security_cfm+0x3f/0x4b0 net/bluetooth/rfcomm/core.c:2222
but task is already holding lock:
ffffffff90f55cc0 (hci_cb_list_lock){+.+.}-{4:4}, at: hci_encrypt_cfm+0x11b/0x740 include/net/bluetooth/hci_core.h:2239
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (hci_cb_list_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
hci_connect_cfm include/net/bluetooth/hci_core.h:2163 [inline]
hci_remote_features_evt+0x485/0x9b0 net/bluetooth/hci_event.c:3786
hci_event_func net/bluetooth/hci_event.c:7887 [inline]
hci_event_packet+0x8e9/0xcd0 net/bluetooth/hci_event.c:7938
hci_rx_work+0x451/0xfc0 net/bluetooth/hci_core.c:4053
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396
process_scheduled_works kernel/workqueue.c:3479 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #1 (&hdev->lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
l2cap_chan_connect+0xac/0x2110 net/bluetooth/l2cap_core.c:7281
l2cap_sock_connect+0x37a/0x770 net/bluetooth/l2cap_sock.c:255
kernel_connect+0x107/0x160 net/socket.c:3755
rfcomm_session_create net/bluetooth/rfcomm/core.c:808 [inline]
__rfcomm_dlc_open net/bluetooth/rfcomm/core.c:385 [inline]
rfcomm_dlc_open+0x838/0xac0 net/bluetooth/rfcomm/core.c:428
rfcomm_sock_connect+0x42c/0x690 net/bluetooth/rfcomm/sock.c:419
connect_socket net/socket.c:2141 [inline]
connect_socket net/socket.c:2131 [inline]
__sys_connect_file+0x146/0x1a0 net/socket.c:2166
__sys_connect+0x141/0x170 net/socket.c:2183
__do_sys_connect net/socket.c:2189 [inline]
__se_sys_connect net/socket.c:2186 [inline]
__x64_sys_connect+0x72/0xb0 net/socket.c:2186
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (rfcomm_mutex){+.+.}-{4:4}:
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3209
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x1528/0x1f40 kernel/locking/lockdep.c:5288
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
rfcomm_security_cfm+0x3f/0x4b0 net/bluetooth/rfcomm/core.c:2222
hci_encrypt_cfm+0x18e/0x740 include/net/bluetooth/hci_core.h:2242
hci_encrypt_change_evt+0x3e1/0xfb0 net/bluetooth/hci_event.c:3715
hci_event_func net/bluetooth/hci_event.c:7887 [inline]
hci_event_packet+0x8e9/0xcd0 net/bluetooth/hci_event.c:7938
hci_rx_work+0x451/0xfc0 net/bluetooth/hci_core.c:4053
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396
process_scheduled_works kernel/workqueue.c:3479 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(hci_cb_list_lock);
lock(&hdev->lock);
lock(hci_cb_list_lock);
lock(rfcomm_mutex);
*** DEADLOCK ***
locks held by kworker/u9:1/4919: 4, last CPU#1:
#0: ffff88807ad07140 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work+0x1466/0x1b10 kernel/workqueue.c:3371
#1: ffffc90002657d08 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_one_work+0xa2c/0x1b10 kernel/workqueue.c:3372
#2: ffff8880700480b8 (&hdev->lock){+.+.}-{4:4}, at: hci_encrypt_change_evt+0x83/0xfb0 net/bluetooth/hci_event.c:3627
#3: ffffffff90f55cc0 (hci_cb_list_lock){+.+.}-{4:4}, at: hci_encrypt_cfm+0x11b/0x740 include/net/bluetooth/hci_core.h:2239
stack backtrace:
CPU: 1 UID: 0 PID: 4919 Comm: kworker/u9:1 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2026
Workqueue: hci0 hci_rx_work
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_circular_bug.cold+0x178/0x1be kernel/locking/lockdep.c:2087
check_noncircular+0x146/0x160 kernel/locking/lockdep.c:2219
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3209
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x1528/0x1f40 kernel/locking/lockdep.c:5288
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
rfcomm_security_cfm+0x3f/0x4b0 net/bluetooth/rfcomm/core.c:2222
hci_encrypt_cfm+0x18e/0x740 include/net/bluetooth/hci_core.h:2242
hci_encrypt_change_evt+0x3e1/0xfb0 net/bluetooth/hci_event.c:3715
hci_event_func net/bluetooth/hci_event.c:7887 [inline]
hci_event_packet+0x8e9/0xcd0 net/bluetooth/hci_event.c:7938
hci_rx_work+0x451/0xfc0 net/bluetooth/hci_core.c:4053
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396
process_scheduled_works kernel/workqueue.c:3479 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Forwarded: [PATCH v3] Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex
2026-08-29 15:29 [syzbot] [bluetooth?] possible deadlock in rfcomm_security_cfm syzbot
2026-09-20 16:08 ` syzbot
@ 2026-09-21 6:23 ` syzbot
1 sibling, 0 replies; 3+ messages in thread
From: syzbot @ 2026-09-21 6:23 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH v3] Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex
Author: mikhail.v.gavrilov@gmail.com
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 518e5b794c06
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: 759c185d0bbd ("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(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index f7463f092283..227ccc7da848 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -62,10 +62,9 @@ static void rfcomm_make_uih(struct sk_buff *skb, u8 addr);
static void rfcomm_process_connect(struct rfcomm_session *s);
-static struct rfcomm_session *rfcomm_session_create(bdaddr_t *src,
- bdaddr_t *dst,
- u8 sec_level,
- int *err);
+static struct socket *rfcomm_session_connect(bdaddr_t *src, bdaddr_t *dst,
+ u8 sec_level, int *err);
+static struct rfcomm_session *rfcomm_session_add(struct socket *sock, int state);
static struct rfcomm_session *rfcomm_session_get(bdaddr_t *src, bdaddr_t *dst);
static struct rfcomm_session *rfcomm_session_del(struct rfcomm_session *s);
@@ -365,28 +364,17 @@ static int rfcomm_check_channel(u8 channel)
return channel < 1 || channel > 30;
}
-static int __rfcomm_dlc_open(struct rfcomm_dlc *d, bdaddr_t *src, bdaddr_t *dst, u8 channel)
+static int __rfcomm_dlc_open(struct rfcomm_dlc *d, struct rfcomm_session *s,
+ u8 channel)
{
- struct rfcomm_session *s;
- int err = 0;
u8 dlci;
- BT_DBG("dlc %p state %ld %pMR -> %pMR channel %d",
- d, d->state, src, dst, channel);
-
- if (rfcomm_check_channel(channel))
- return -EINVAL;
+ BT_DBG("dlc %p state %ld session %p channel %d",
+ d, d->state, s, channel);
if (d->state != BT_OPEN && d->state != BT_CLOSED)
return 0;
- s = rfcomm_session_get(src, dst);
- if (!s) {
- s = rfcomm_session_create(src, dst, d->sec_level, &err);
- if (!s)
- return err;
- }
-
dlci = __dlci(__session_dir(s), channel);
/* Check if DLCI already exists */
@@ -421,14 +409,72 @@ static int __rfcomm_dlc_open(struct rfcomm_dlc *d, bdaddr_t *src, bdaddr_t *dst,
int rfcomm_dlc_open(struct rfcomm_dlc *d, bdaddr_t *src, bdaddr_t *dst, u8 channel)
{
- int r;
+ struct rfcomm_session *s;
+ struct socket *sock;
+ int err;
+
+ BT_DBG("dlc %p state %ld %pMR -> %pMR channel %d",
+ d, d->state, src, dst, channel);
+
+ if (rfcomm_check_channel(channel))
+ return -EINVAL;
rfcomm_lock();
- r = __rfcomm_dlc_open(d, src, dst, channel);
+ /* Do not page the remote device for a DLC that cannot be opened
+ * anyway. __rfcomm_dlc_open() looks at the state again once the
+ * lock has been re-acquired below.
+ */
+ if (d->state != BT_OPEN && d->state != BT_CLOSED) {
+ rfcomm_unlock();
+ return 0;
+ }
+ s = rfcomm_session_get(src, dst);
+ if (s) {
+ err = __rfcomm_dlc_open(d, s, channel);
+ rfcomm_unlock();
+ return err;
+ }
rfcomm_unlock();
- return r;
+
+ /* There is no session for this pair yet. kernel_connect() ends up in
+ * l2cap_chan_connect(), which takes hdev->lock, and the HCI event
+ * path takes rfcomm_mutex while holding hdev->lock, so the socket has
+ * to be connected with rfcomm_mutex released.
+ */
+ sock = rfcomm_session_connect(src, dst, d->sec_level, &err);
+ if (!sock)
+ return err;
+
+ rfcomm_lock();
+
+ /* Another opener may have added a session for the same pair in the
+ * meantime; that one is used and this socket is dropped.
+ */
+ s = rfcomm_session_get(src, dst);
+ if (!s) {
+ s = rfcomm_session_add(sock, BT_BOUND);
+ if (s) {
+ s->initiator = 1;
+ sock = NULL;
+ }
+ }
+
+ err = s ? __rfcomm_dlc_open(d, s, channel) : -ENOMEM;
+
+ rfcomm_unlock();
+
+ if (sock)
+ sock_release(sock);
+
+ /* Over an existing ACL link the connection can complete before the
+ * session reaches the list, and that wakeup is then lost, so let
+ * krfcommd look at the socket state now.
+ */
+ rfcomm_schedule();
+
+ return err;
}
static void __rfcomm_dlc_disconn(struct rfcomm_dlc *d)
@@ -757,12 +803,12 @@ static struct rfcomm_session *rfcomm_session_close(struct rfcomm_session *s,
return rfcomm_session_del(s);
}
-static struct rfcomm_session *rfcomm_session_create(bdaddr_t *src,
- bdaddr_t *dst,
- u8 sec_level,
- int *err)
+/* Creates the L2CAP socket a new session will run on and starts connecting
+ * it. Must be called with rfcomm_mutex released.
+ */
+static struct socket *rfcomm_session_connect(bdaddr_t *src, bdaddr_t *dst,
+ u8 sec_level, int *err)
{
- struct rfcomm_session *s = NULL;
struct sockaddr_l2 addr;
struct socket *sock;
struct sock *sk;
@@ -792,24 +838,16 @@ static struct rfcomm_session *rfcomm_session_create(bdaddr_t *src,
l2cap_pi(sk)->chan->mode = L2CAP_MODE_ERTM;
release_sock(sk);
- s = rfcomm_session_add(sock, BT_BOUND);
- if (!s) {
- *err = -ENOMEM;
- goto failed;
- }
-
- s->initiator = 1;
-
bacpy(&addr.l2_bdaddr, dst);
addr.l2_family = AF_BLUETOOTH;
addr.l2_psm = cpu_to_le16(L2CAP_PSM_RFCOMM);
addr.l2_cid = 0;
addr.l2_bdaddr_type = BDADDR_BREDR;
*err = kernel_connect(sock, (struct sockaddr_unsized *)&addr, sizeof(addr), O_NONBLOCK);
- if (*err == 0 || *err == -EINPROGRESS)
- return s;
+ if (*err && *err != -EINPROGRESS)
+ goto failed;
- return rfcomm_session_del(s);
+ return sock;
failed:
sock_release(sock);
--
2.55.0
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-21 6:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-29 15:29 [syzbot] [bluetooth?] possible deadlock in rfcomm_security_cfm syzbot
2026-09-20 16:08 ` syzbot
2026-09-21 6:23 ` Forwarded: [PATCH v3] Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex syzbot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®