PT-2026-52351 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53256
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: hold listener socket in rfcomm connect ind()
rfcomm get sock by channel() scans rfcomm sk list under the list lock,
but returns the selected listener after dropping that lock without
taking a reference. rfcomm connect ind() 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:
rfcomm connect ind(): listener close:
- Find parent in 1. close() enters rfcomm get sock by channel() rfcomm sock release().
- Drop rfcomm sk list.lock 2. rfcomm sock shutdown() without pinning parent. closes the listener.
- Call lock sock(parent) and 3. rfcomm sock kill() bt accept enqueue(parent, unlinks and puts parent. sk, true).
- Read parent flags and may 4. parent can be freed. call sk state change().
If close wins the race, parent can be freed before
rfcomm connect ind() reaches lock sock(), bt accept enqueue(), or the
deferred-setup callback.
Take a reference on the listener before leaving rfcomm sk list.lock.
After lock sock() succeeds, recheck that it is still in BT LISTEN
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 lock sock nested() from
rfcomm connect ind(), with the freeing stack going through
rfcomm sock kill() and rfcomm sock release().
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux