[PATCH] Bluetooth: RFCOMM: serialize security confirmation handling

[PATCH] Bluetooth: RFCOMM: serialize security confirmation handling

[Chengfeng Ye]

rfcomm_security_cfm() looks up a session on session_list and then walks
its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown
uses rfcomm_mutex, krfcommd can close and free the same session and DLCs
concurrently:

  hci_rx_work                    krfcommd
  -----------                    ---------
  rfcomm_session_get()
                                 rfcomm_lock()
                                 rfcomm_session_close()
                                   rfcomm_dlc_unlink()
                                   rfcomm_session_del()
                                     kfree(s)
                                 rfcomm_unlock()
  walk s->dlcs

The callback can then read a freed session list head and touch freed DLCs
while updating their flags or timers.

Serialize the session lookup and DLC traversal in rfcomm_security_cfm()
with rfcomm_mutex. This matches the existing RFCOMM session lifetime
rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink()
from tearing the objects down while the callback is using them.

KASAN reported:

  BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440
  Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89
  Workqueue: hci0 hci_rx_work
  Call Trace:
   rfcomm_security_cfm+0x41c/0x440
   hci_encrypt_cfm+0x139/0x590
   hci_encrypt_change_evt+0x37b/0xc40
   hci_event_packet+0x71b/0xb20
   hci_rx_work+0x293/0x730
  Allocated by task 69:
   rfcomm_session_add+0x9e/0x2f0
   rfcomm_run+0x44b/0x41e0
  Freed by task 69:
   kfree+0x131/0x3c0
   rfcomm_session_del+0x188/0x220
   rfcomm_run+0x1985/0x41e0

Fixes: 08c30aca9e698faddebd34f81e1196295f9dc063 ("Bluetooth: Remove RFCOMM session refcnt")
Cc: stable@vger.kernel.org
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
---
 net/bluetooth/rfcomm/core.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 9cdfea666a2c..5d150e8623d5 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2213,9 +2213,13 @@ static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
 
 	BT_DBG("conn %p status 0x%02x encrypt 0x%02x", conn, status, encrypt);
 
+	rfcomm_lock();
+
 	s = rfcomm_session_get(&conn->hdev->bdaddr, &conn->dst);
-	if (!s)
+	if (!s) {
+		rfcomm_unlock();
 		return;
+	}
 
 	list_for_each_entry_safe(d, n, &s->dlcs, list) {
 		if (test_and_clear_bit(RFCOMM_SEC_PENDING, &d->flags)) {
@@ -2247,6 +2251,8 @@ static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
 			set_bit(RFCOMM_AUTH_REJECT, &d->flags);
 	}
 
+	rfcomm_unlock();
+
 	rfcomm_schedule();
 }
 
-- 
2.43.0

Re: [PATCH] Bluetooth: RFCOMM: serialize security confirmation handling

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Sun, 23 Aug 2026 00:43:41 +0800 you wrote:
> rfcomm_security_cfm() looks up a session on session_list and then walks
> its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown
> uses rfcomm_mutex, krfcommd can close and free the same session and DLCs
> concurrently:
> 
>   hci_rx_work                    krfcommd
> 
> [...]

Here is the summary with links:
  - Bluetooth: RFCOMM: serialize security confirmation handling
    https://git.kernel.org/bluetooth/bluetooth-next/c/40c621391de9

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH] Bluetooth: RFCOMM: serialize security confirmation handling

[Pauli Virtanen]

Hi,

ma, 2026-08-24 kello 16:50 +0000, patchwork-bot+bluetooth@kernel.org
kirjoitti:
> Hello:
> 
> This patch was applied to bluetooth/bluetooth-next.git (master)
> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
> 
> On Sun, 23 Aug 2026 00:43:41 +0800 you wrote:
> > rfcomm_security_cfm() looks up a session on session_list and then walks
> > its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown
> > uses rfcomm_mutex, krfcommd can close and free the same session and DLCs
> > concurrently:
> > 
> >   hci_rx_work                    krfcommd
> > 
> > [...]
> 
> Here is the summary with links:
>   - Bluetooth: RFCOMM: serialize security confirmation handling
>     https://git.kernel.org/bluetooth/bluetooth-next/c/40c621391de9
> 
> You are awesome, thank you!

I'm a bit too late now, but Sashiko report had some valid concerns
about lock ordering in this one:
https://sashiko.dev/#/patchset/20260822164341.3750491-1-nicoyip.dev%40gmail.com

Running both BlueZ l2cap-tester and rfcomm-tester (so lockdep sees more
paths) in same boot you get lockdep splat.

Not immediately clear that a real deadlock could be triggered, but
lockdep thinks the ordering is now inconsistent.


======================================================
WARNING: possible circular locking dependency detected
7.2.0-rc6-01463-gfe3897b4ab57 #994 Not tainted
------------------------------------------------------
rfcomm-tester/364 is trying to acquire lock:
ffff8880027d40b0 (&hdev->lock){+.+.}-{4:4}, at: l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)

but task is already holding lock:
ffffffff99499f58 (rfcomm_mutex){+.+.}-{4:4}, at: rfcomm_dlc_open (net/bluetooth/rfcomm/core.c:426)

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (rfcomm_mutex){+.+.}-{4:4}:
__mutex_lock (kernel/locking/mutex.c:646)
rfcomm_security_cfm (net/bluetooth/rfcomm/core.c:2222)
hci_auth_complete_evt (./include/net/bluetooth/hci_core.h:2246 net/bluetooth/hci_event.c:3554)
hci_event_packet (net/bluetooth/hci_event.c:7887)
hci_rx_work (net/bluetooth/hci_core.c:4041)
process_scheduled_works (kernel/workqueue.c:3322)
worker_thread (kernel/workqueue.c:3486)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)

-> #1 (hci_cb_list_lock){+.+.}-{4:4}:
__mutex_lock (kernel/locking/mutex.c:646)
hci_remote_ext_features_evt (./include/net/bluetooth/hci_core.h:2207 net/bluetooth/hci_event.c:5030)
hci_event_packet (net/bluetooth/hci_event.c:7887)
hci_rx_work (net/bluetooth/hci_core.c:4041)
process_scheduled_works (kernel/workqueue.c:3322)
worker_thread (kernel/workqueue.c:3486)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)

-> #0 (&hdev->lock){+.+.}-{4:4}:
__lock_acquire (kernel/locking/lockdep.c:3165)
lock_acquire (kernel/locking/lockdep.c:5868)
__mutex_lock (kernel/locking/mutex.c:646)
l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)
l2cap_sock_connect (net/bluetooth/l2cap_sock.c:255)
kernel_connect (net/socket.c:3726)
rfcomm_dlc_open (net/bluetooth/rfcomm/core.c:808)
rfcomm_sock_connect (net/bluetooth/rfcomm/sock.c:421)
__sys_connect (net/socket.c:2135)
__x64_sys_connect (net/socket.c:2160 net/socket.c:2157 net/socket.c:2157)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

other info that might help us debug this:

Chain exists of:
&hdev->lock --> hci_cb_list_lock --> rfcomm_mutex

Possible unsafe locking scenario:

CPU0                    CPU1
----                    ----
lock(rfcomm_mutex);
                        lock(hci_cb_list_lock);
                        lock(rfcomm_mutex);
lock(&hdev->lock);

*** DEADLOCK ***

1 lock held by rfcomm-tester/364:
#0: ffffffff99499f58 (rfcomm_mutex){+.+.}-{4:4}, at: rfcomm_dlc_open (net/bluetooth/rfcomm/core.c:426)

stack backtrace:
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-10.fc44 06/10/2025
Call Trace:
<TASK>
print_circular_bug (kernel/locking/lockdep.c:2043)
check_noncircular (kernel/locking/lockdep.c:2175)
__lock_acquire (kernel/locking/lockdep.c:3165)
? stack_trace_save (kernel/stacktrace.c:122)
? add_lock_to_list (./include/linux/find.h:391 kernel/locking/lockdep.c:1403 kernel/locking/lockdep.c:1434)
? __lock_acquire (kernel/locking/lockdep.c:191 kernel/locking/lockdep.c:3912 kernel/locking/lockdep.c:5237)
lock_acquire (kernel/locking/lockdep.c:5868)
? l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)
__mutex_lock (kernel/locking/mutex.c:646)
? l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)
? lock_acquire (kernel/locking/lockdep.c:5868)
? hci_get_route (net/bluetooth/hci_conn.c:1331)
? lock_release (kernel/locking/lockdep.c:5350)
? hci_get_route (net/bluetooth/hci_conn.c:1379)
? l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)
l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)
? l2cap_sock_connect (net/bluetooth/l2cap_sock.c:193)
l2cap_sock_connect (net/bluetooth/l2cap_sock.c:255)
kernel_connect (net/socket.c:3726)
rfcomm_dlc_open (net/bluetooth/rfcomm/core.c:808)
rfcomm_sock_connect (net/bluetooth/rfcomm/sock.c:421)
? __pfx_rfcomm_sock_connect (net/bluetooth/rfcomm/sock.c:?)
__sys_connect (net/socket.c:2135)
__x64_sys_connect (net/socket.c:2160 net/socket.c:2157 net/socket.c:2157)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
? trace_hardirqs_off (./include/trace/events/preemptirq.h:36)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
RIP: 0033:0x7f2b9c05854e
Code: 4d 89 d8 e8 b4 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 03 ff ff ff 0f 1f 00 f3 0f 1e fa
All code
========
   0:	4d 89 d8             	mov    %r11,%r8
   3:	e8 b4 bd 00 00       	call   0xbdbc
   8:	4c 8b 5d f8          	mov    -0x8(%rbp),%r11
   c:	41 8b 93 08 03 00 00 	mov    0x308(%r11),%edx
  13:	59                   	pop    %rcx
  14:	5e                   	pop    %rsi
  15:	48 83 f8 fc          	cmp    $0xfffffffffffffffc,%rax
  19:	74 11                	je     0x2c
  1b:	c9                   	leave
  1c:	c3                   	ret
  1d:	0f 1f 80 00 00 00 00 	nopl   0x0(%rax)
  24:	48 8b 45 10          	mov    0x10(%rbp),%rax
  28:	0f 05                	syscall
  2a:*	c9                   	leave		<-- trapping instruction
  2b:	c3                   	ret
  2c:	83 e2 39             	and    $0x39,%edx
  2f:	83 fa 08             	cmp    $0x8,%edx
  32:	75 e7                	jne    0x1b
  34:	e8 03 ff ff ff       	call   0xffffffffffffff3c
  39:	0f 1f 00             	nopl   (%rax)
  3c:	f3 0f 1e fa          	endbr64

Code starting with the faulting instruction
===========================================
   0:	c9                   	leave
   1:	c3                   	ret
   2:	83 e2 39             	and    $0x39,%edx
   5:	83 fa 08             	cmp    $0x8,%edx
   8:	75 e7                	jne    0xfffffffffffffff1
   a:	e8 03 ff ff ff       	call   0xffffffffffffff12
   f:	0f 1f 00             	nopl   (%rax)
  12:	f3 0f 1e fa          	endbr64
RSP: 002b:00007fff41018e50 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00000000004fbee0 RCX: 00007f2b9c05854e
RDX: 000000000000000a RSI: 00007b2b99ad7e60 RDI: 000000000000000d
RBP: 00007fff41018e60 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007b2b99ad7e40
R13: 00007b2b99ad7e60 R14: 000000000000000d R15: 00007b8b9ade0140
</TASK>


-- 
Pauli Virtanen

Re: [PATCH] Bluetooth: RFCOMM: serialize security confirmation handling

[Luiz Augusto von Dentz]

Hi Pauli,

On Mon, Aug 24, 2026 at 3:38 PM Pauli Virtanen <pav@iki.fi> wrote:
>
> Hi,
>
> ma, 2026-08-24 kello 16:50 +0000, patchwork-bot+bluetooth@kernel.org
> kirjoitti:
> > Hello:
> >
> > This patch was applied to bluetooth/bluetooth-next.git (master)
> > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
> >
> > On Sun, 23 Aug 2026 00:43:41 +0800 you wrote:
> > > rfcomm_security_cfm() looks up a session on session_list and then walks
> > > its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown
> > > uses rfcomm_mutex, krfcommd can close and free the same session and DLCs
> > > concurrently:
> > >
> > >   hci_rx_work                    krfcommd
> > >
> > > [...]
> >
> > Here is the summary with links:
> >   - Bluetooth: RFCOMM: serialize security confirmation handling
> >     https://git.kernel.org/bluetooth/bluetooth-next/c/40c621391de9
> >
> > You are awesome, thank you!
>
> I'm a bit too late now, but Sashiko report had some valid concerns
> about lock ordering in this one:
> https://sashiko.dev/#/patchset/20260822164341.3750491-1-nicoyip.dev%40gmail.com
>
> Running both BlueZ l2cap-tester and rfcomm-tester (so lockdep sees more
> paths) in same boot you get lockdep splat.

I didn't know about this trick, so I wonder if we should do something
about it. Testing with just rfcomm-tester should show this, or perhaps
we need to change the CI to run all tests under the same test-runner
instance so lockdep learns about all the code paths.

> Not immediately clear that a real deadlock could be triggered, but
> lockdep thinks the ordering is now inconsistent.
>
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 7.2.0-rc6-01463-gfe3897b4ab57 #994 Not tainted
> ------------------------------------------------------
> rfcomm-tester/364 is trying to acquire lock:
> ffff8880027d40b0 (&hdev->lock){+.+.}-{4:4}, at: l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)
>
> but task is already holding lock:
> ffffffff99499f58 (rfcomm_mutex){+.+.}-{4:4}, at: rfcomm_dlc_open (net/bluetooth/rfcomm/core.c:426)
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (rfcomm_mutex){+.+.}-{4:4}:
> __mutex_lock (kernel/locking/mutex.c:646)
> rfcomm_security_cfm (net/bluetooth/rfcomm/core.c:2222)
> hci_auth_complete_evt (./include/net/bluetooth/hci_core.h:2246 net/bluetooth/hci_event.c:3554)
> hci_event_packet (net/bluetooth/hci_event.c:7887)
> hci_rx_work (net/bluetooth/hci_core.c:4041)
> process_scheduled_works (kernel/workqueue.c:3322)
> worker_thread (kernel/workqueue.c:3486)
> kthread (kernel/kthread.c:436)
> ret_from_fork (arch/x86/kernel/process.c:158)
> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
>
> -> #1 (hci_cb_list_lock){+.+.}-{4:4}:
> __mutex_lock (kernel/locking/mutex.c:646)
> hci_remote_ext_features_evt (./include/net/bluetooth/hci_core.h:2207 net/bluetooth/hci_event.c:5030)
> hci_event_packet (net/bluetooth/hci_event.c:7887)
> hci_rx_work (net/bluetooth/hci_core.c:4041)
> process_scheduled_works (kernel/workqueue.c:3322)
> worker_thread (kernel/workqueue.c:3486)
> kthread (kernel/kthread.c:436)
> ret_from_fork (arch/x86/kernel/process.c:158)
> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
>
> -> #0 (&hdev->lock){+.+.}-{4:4}:
> __lock_acquire (kernel/locking/lockdep.c:3165)
> lock_acquire (kernel/locking/lockdep.c:5868)
> __mutex_lock (kernel/locking/mutex.c:646)
> l2cap_chan_connect (net/bluetooth/l2cap_core.c:7271)
> l2cap_sock_connect (net/bluetooth/l2cap_sock.c:255)
> kernel_connect (net/socket.c:3726)

Interesting, I though the kernel_connect would actually behave as a
syscall and use it own thread so it wouldn't result into
l2cap_chan_connect, in that case it is probably useless to use it in
place of l2cap_chan_connect directly, so we may take the opportunity
and clean this up.

> rfcomm_dlc_open (net/bluetooth/rfcomm/core.c:808)
> rfcomm_sock_connect (net/bluetooth/rfcomm/sock.c:421)
> __sys_connect (net/socket.c:2135)
> __x64_sys_connect (net/socket.c:2160 net/socket.c:2157 net/socket.c:2157)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>
> other info that might help us debug this:
>
> Chain exists of:
> &hdev->lock --> hci_cb_list_lock --> rfcomm_mutex
>
> Possible unsafe locking scenario:
>
> CPU0                    CPU1
> ----                    ----
> lock(rfcomm_mutex);
>                         lock(hci_cb_list_lock);
>                         lock(rfcomm_mutex);
> lock(&hdev->lock);
>
> *** DEADLOCK ***
>
> 1 lock held by rfcomm-tester/364:
> #0: ffffffff99499f58 (rfcomm_mutex){+.+.}-{4:4}, at: rfcomm_dlc_open (net/bluetooth/rfcomm/core.c:426)

Re: [PATCH] Bluetooth: RFCOMM: serialize security confirmation handling

[Chengfeng Ye]

Hi Luiz,

On Tue, Aug 25, 2026 at 4:24 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Interesting, I though the kernel_connect would actually behave as a
> syscall and use it own thread so it wouldn't result into
> l2cap_chan_connect, in that case it is probably useless to use it in
> place of l2cap_chan_connect directly, so we may take the opportunity
> and clean this up.

Sorry for the negligence of the possible deadlock cycle. Could we
avoid the locking cycle by directly moving the session lookup and DLC
walk onto krfcommd so rfcomm_security_cfm() no longer takes
rfcomm_mutex from hci_rx_work? If we need a fix like this, should I
send a follow-up patch or send a v2?

Best regards,
Chengfeng

Re: [PATCH] Bluetooth: RFCOMM: serialize security confirmation handling

[Luiz Augusto von Dentz]

Hi Chengfeng,

On Tue, Aug 25, 2026 at 2:46 PM Chengfeng Ye <nicoyip.dev@gmail.com> wrote:
>
> Hi Luiz,
>
> On Tue, Aug 25, 2026 at 4:24 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > Interesting, I though the kernel_connect would actually behave as a
> > syscall and use it own thread so it wouldn't result into
> > l2cap_chan_connect, in that case it is probably useless to use it in
> > place of l2cap_chan_connect directly, so we may take the opportunity
> > and clean this up.
>
> Sorry for the negligence of the possible deadlock cycle. Could we
> avoid the locking cycle by directly moving the session lookup and DLC
> walk onto krfcommd so rfcomm_security_cfm() no longer takes
> rfcomm_mutex from hci_rx_work? If we need a fix like this, should I
> send a follow-up patch or send a v2?

It is a possible solution, that said couldn't we do the walk using
rcu_read_lock/list_for_each_entry_rcu/rcu_read_unlock?

> Best regards,
> Chengfeng



-- 
Luiz Augusto von Dentz