CVE-2026-89569: Bluetooth: RFCOMM: serialize security confirmation handling
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: serialize security confirmation handling
rfcommsecuritycfm() looks up a session on sessionlist and then walks its DLC list without holding rfcommmutex. Since RFCOMM session teardown uses rfcommmutex, krfcommd can close and free the same session and DLCs concurrently:
hcirxwork krfcommd ----------- --------- rfcommsessionget() rfcommlock() rfcommsessionclose() rfcommdlcunlink() rfcommsessiondel() kfree(s) rfcommunlock() 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 rfcommsecuritycfm() with rfcommmutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcommsessiondel() / rfcommdlcunlink() from tearing the objects down while the callback is using them.
KASAN reported:
BUG: KASAN: slab-use-after-free in rfcommsecuritycfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hcirxwork Call Trace: rfcommsecuritycfm+0x41c/0x440 hciencryptcfm+0x139/0x590 hciencryptchangeevt+0x37b/0xc40 hcieventpacket+0x71b/0xb20 hcirxwork+0x293/0x730 Allocated by task 69: rfcommsessionadd+0x9e/0x2f0 rfcommrun+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcommsessiondel+0x188/0x220 rfcommrun+0x1985/0x41e0
Affected Software
Event History
Frequently Asked Questions
What runtime conditions are required for this issue to occur?
An RFCOMM security confirmation callback must look up and traverse a session's DLC list while another context is tearing down that same RFCOMM session. The race involves hci_rx_work handling the confirmation concurrently with krfcommd closing, unlinking, deleting, and freeing the session and DLCs.
How can administrators recognize that this race has occurred?
KASAN may report a slab use-after-free in rfcomm_security_cfm, potentially from a kworker processing hci_rx_work. The reported call path includes rfcomm_security_cfm followed by hci_encrypt_cfm and an encryption-change event handler.