Re: [PATCH] Bluetooth: RFCOMM: serialize session teardown
From: Ali Ahmet Memis
Date: Fri Aug 21 2026 - 15:23:26 EST
Hi,
On Sat, Aug 22, 2026 at 01:45:14AM +0800, Chengfeng Ye wrote:
> rfcomm_kill_listener() walks session_list and deletes every session
> without holding rfcomm_mutex.
I agree with that observation but I don't think this race is reachable. I
also could not reproduce the reported splat.
I tested 7.2-rc5 with KASAN and RFCOMM as a module. An open RFCOMM socket
keeps rfcomm.ko pinned so the module cannot be unloaded while connect() is
running. Even with forced unloads and a widened add/drop window, I only
hit execution from freed module text. I never saw a UAF in
rfcomm_session_del().
The splat also looks like it came from a built-in RFCOMM build. The
missing module tag and the way rfcomm_exit() works in that case make the
reported path unlikely.
Could you send the full report and the reproducer? In particular the
"buggy address" block and both full stacks would help. faddr2line on your
vmlinux should also show which traversal the offset points to.
The locking itself is safe but I don't think the changelog currently
describes a reachable race. There may be a more relevant unlocked
session_list access in rfcomm_security_cfm().