[syzbot] [bluetooth?] possible deadlock in rfcomm_dlc_close

[syzbot] [bluetooth?] possible deadlock in rfcomm_dlc_close

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    50d05c7c76c9 Merge tag 'landlock-7.3-rc3' of git://git.ker..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15ad0905580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=0cece8fa7d83523f47a3
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=13ad0905580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12752c8e580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-50d05c7c.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6f77d29903f3/vmlinux-50d05c7c.xz
kernel image: https://storage.googleapis.com/syzbot-assets/23b2961d9c5d/bzImage-50d05c7c.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0cece8fa7d83523f47a3@syzkaller.appspotmail.com

======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.0.67/5982 is trying to acquire lock:
ffffffff90f80f40 (rfcomm_mutex){+.+.}-{4:4}, at: rfcomm_dlc_close+0x33/0x240 net/bluetooth/rfcomm/core.c:508

but task is already holding lock:
ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sock_close net/bluetooth/rfcomm/sock.c:245 [inline]
ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sock_cleanup_listen net/bluetooth/rfcomm/sock.c:190 [inline]
ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: __rfcomm_sock_close+0x1c3/0x300 net/bluetooth/rfcomm/sock.c:224

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}:
       lock_acquire kernel/locking/lockdep.c:5942 [inline]
       lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
       lock_sock_nested+0x41/0xf0 net/core/sock.c:3830
       lock_sock include/net/sock.h:1713 [inline]
       rfcomm_connect_ind+0x327/0x9e0 net/bluetooth/rfcomm/sock.c:968
       rfcomm_recv_pn net/bluetooth/rfcomm/core.c:1509 [inline]
       rfcomm_recv_mcc net/bluetooth/rfcomm/core.c:1727 [inline]
       rfcomm_recv_frame net/bluetooth/rfcomm/core.c:1868 [inline]
       rfcomm_process_rx net/bluetooth/rfcomm/core.c:2020 [inline]
       rfcomm_process_sessions net/bluetooth/rfcomm/core.c:2114 [inline]
       rfcomm_run+0x438b/0x54c0 net/bluetooth/rfcomm/core.c:2204
       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

-> #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_dlc_close+0x33/0x240 net/bluetooth/rfcomm/core.c:508
       __rfcomm_sock_close+0x181/0x300 net/bluetooth/rfcomm/sock.c:231
       rfcomm_sock_close net/bluetooth/rfcomm/sock.c:246 [inline]
       rfcomm_sock_cleanup_listen net/bluetooth/rfcomm/sock.c:190 [inline]
       __rfcomm_sock_close+0x1d2/0x300 net/bluetooth/rfcomm/sock.c:224
       rfcomm_sock_shutdown+0x111/0x250 net/bluetooth/rfcomm/sock.c:920
       rfcomm_sock_release+0x61/0x1a0 net/bluetooth/rfcomm/sock.c:941
       __sock_release+0xb3/0x260 net/socket.c:735
       sock_close+0x1c/0x30 net/socket.c:1526
       __fput+0x3ff/0xb50 fs/file_table.c:512
       task_work_run+0x150/0x240 kernel/task_work.c:233
       resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
       __exit_to_user_mode_loop kernel/entry/common.c:70 [inline]
       exit_to_user_mode_loop+0x1d8/0x700 kernel/entry/common.c:101
       __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
       syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
       syscall_exit_to_user_mode include/linux/entry-common.h:336 [inline]
       do_syscall_64+0x661/0x790 arch/x86/entry/syscall_64.c:89
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
                               lock(rfcomm_mutex);
                               lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
  lock(rfcomm_mutex);

 *** DEADLOCK ***

locks held by syz.0.67/5982: 2, last CPU#0:
 #0: ffff88805501bbc0 (&sb->s_type->i_mutex_key#13){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:1024 [inline]
 #0: ffff88805501bbc0 (&sb->s_type->i_mutex_key#13){+.+.}-{4:4}, at: __sock_release+0x86/0x260 net/socket.c:734
 #1: ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1713 [inline]
 #1: ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sock_close net/bluetooth/rfcomm/sock.c:245 [inline]
 #1: ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sock_cleanup_listen net/bluetooth/rfcomm/sock.c:190 [inline]
 #1: ffff8880234b9260 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: __rfcomm_sock_close+0x1c3/0x300 net/bluetooth/rfcomm/sock.c:224

stack backtrace:
CPU: 0 UID: 0 PID: 5982 Comm: syz.0.67 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
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_dlc_close+0x33/0x240 net/bluetooth/rfcomm/core.c:508
 __rfcomm_sock_close+0x181/0x300 net/bluetooth/rfcomm/sock.c:231
 rfcomm_sock_close net/bluetooth/rfcomm/sock.c:246 [inline]
 rfcomm_sock_cleanup_listen net/bluetooth/rfcomm/sock.c:190 [inline]
 __rfcomm_sock_close+0x1d2/0x300 net/bluetooth/rfcomm/sock.c:224
 rfcomm_sock_shutdown+0x111/0x250 net/bluetooth/rfcomm/sock.c:920
 rfcomm_sock_release+0x61/0x1a0 net/bluetooth/rfcomm/sock.c:941
 __sock_release+0xb3/0x260 net/socket.c:735
 sock_close+0x1c/0x30 net/socket.c:1526
 __fput+0x3ff/0xb50 fs/file_table.c:512
 task_work_run+0x150/0x240 kernel/task_work.c:233
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 __exit_to_user_mode_loop kernel/entry/common.c:70 [inline]
 exit_to_user_mode_loop+0x1d8/0x700 kernel/entry/common.c:101
 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
 syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
 syscall_exit_to_user_mode include/linux/entry-common.h:336 [inline]
 do_syscall_64+0x661/0x790 arch/x86/entry/syscall_64.c:89
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd18819e159
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe0b172838 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: 0000000000000000 RBX: 00007ffe0b172920 RCX: 00007fd18819e159
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 000000000000e138 R08: 0000000000000001 R09: 0000000000000000
R10: 0000001b32a20000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fd188425fac R14: 00007fd188425fa8 R15: 00007fd188425fa0
 </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 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.

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

[PATCH v2] Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup

[Juan Perdomo]

rfcomm_sock_cleanup_listen() closes unaccepted child sockets through
rfcomm_sock_close(), which takes the child socket lock before
rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these
locks in reverse order while handling connections and DLC state changes,
so lockdep reports a possible deadlock.

Close dequeued children without taking their socket lock. The accept queue
owns a reference to each child, and bt_accept_dequeue() locks the child
while unlinking it and clearing its parent pointer.

Dropping the child lock makes it important to prevent a concurrent
rfcomm_connect_ind() from enqueueing a new child after cleanup observes an
empty queue. Set a listening socket to BT_CLOSED while its lock is still
held, before dropping the lock and draining the queue. The state check in
rfcomm_connect_ind() then rejects new children once cleanup starts.

Reported-by: syzbot+0cece8fa7d83523f47a3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=0cece8fa7d83523f47a3
Fixes: b7ce436a5d79 ("Bluetooth: switch to lock_sock in RFCOMM")
Signed-off-by: Juan Perdomo <jcperdomo100@gmail.com>
---
Changes in v2:
- Mark the listener BT_CLOSED under its socket lock before accept-queue
  cleanup, preventing new children from racing with teardown.
- Retest with syzbot after its v1 run exposed the accept-queue race. The
  revised patch completed without triggering an issue:
  https://syzkaller.appspot.com/x/bisect.txt?x=156ca925580000

 net/bluetooth/rfcomm/sock.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 958081adb..e2486bc11 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -242,9 +242,7 @@ static void __rfcomm_sock_close(struct sock *sk)
  */
 static void rfcomm_sock_close(struct sock *sk)
 {
-	lock_sock(sk);
 	__rfcomm_sock_close(sk);
-	release_sock(sk);
 }
 
 static void rfcomm_sock_init(struct sock *sk, struct sock *parent)
@@ -905,6 +903,7 @@ static int rfcomm_sock_compat_ioctl(struct socket *sock, unsigned int cmd, unsig
 static int rfcomm_sock_shutdown(struct socket *sock, int how)
 {
 	struct sock *sk = sock->sk;
+	bool cleanup_listen = false;
 	int err = 0;
 
 	BT_DBG("sock %p, sk %p", sock, sk);
@@ -915,9 +914,17 @@ static int rfcomm_sock_shutdown(struct socket *sock, int how)
 	lock_sock(sk);
 	if (!sk->sk_shutdown) {
 		sk->sk_shutdown = SHUTDOWN_MASK;
+		if (sk->sk_state == BT_LISTEN) {
+			/* Block new children before cleaning up without sk lock. */
+			sk->sk_state = BT_CLOSED;
+			cleanup_listen = true;
+		}
 
 		release_sock(sk);
-		__rfcomm_sock_close(sk);
+		if (cleanup_listen)
+			rfcomm_sock_cleanup_listen(sk);
+		else
+			__rfcomm_sock_close(sk);
 		lock_sock(sk);
 
 		if (sock_flag(sk, SOCK_LINGER) && sk->sk_lingertime &&
-- 
2.50.1 (Apple Git-155)

RE: [v2] Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1163670/

---Test result---

Test Summary:
CheckPatch                    PASS      0.73 seconds
VerifyFixes                   PASS      0.12 seconds
VerifySignedoff               PASS      0.11 seconds
GitLint                       PASS      0.33 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      28.61 seconds
CheckAllWarning               PASS      32.86 seconds
CheckSparse                   PASS      35.62 seconds
BuildKernel32                 PASS      28.84 seconds
CheckKernelLLVM               PASS      32.76 seconds
TestRunnerSetup               PASS      778.63 seconds
TestRunner_rfcomm-tester      PASS      16.86 seconds
IncrementalBuild              PASS      27.40 seconds



https://github.com/bluez/bluetooth-next/pull/758

---
Regards,
Linux Bluetooth