CVE-2026-53256: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: hold listener socket in rfcommconnectind()

rfcommgetsockbychannel() scans rfcommsklist under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcommconnectind() then locks the listener, queues a child socket on it, and may notify it after unlocking it.

The buggy scenario involves two paths, with each column showing the order within that path:

rfcommconnectind(): listener close: 1. Find parent in 1. close() enters rfcommgetsockbychannel() rfcommsockrelease(). 2. Drop rfcommsklist.lock 2. rfcommsockshutdown() without pinning parent. closes the listener. 3. Call locksock(parent) and 3. rfcommsockkill() btacceptenqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call skstatechange().

If close wins the race, parent can be freed before rfcommconnectind() reaches locksock(), btacceptenqueue(), or the deferred-setup callback.

Take a reference on the listener before leaving rfcommsklist.lock. After locksock() succeeds, recheck that it is still in BTLISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use.

KASAN reported a slab-use-after-free in locksocknested() from rfcommconnectind(), with the freeing stack going through rfcommsockkill() and rfcommsockrelease().