CVE-2026-53256
HighCVSS 8.0Exploitation Probability (EPSS)
Low risk18th percentile — higher than 18% of all known CVEs
Summary
A use-after-free vulnerability was found in the Linux kernel's Bluetooth RFCOMM subsystem in the rfcomm_connect_ind() function. The issue stems from missing reference counting on the listening socket during rfcomm_sk_list scanning, allowing a race condition with socket closure and potential exploitation.
Risk Assessment
An attacker within Bluetooth range could trigger a kernel memory corruption, leading to system panic or potential privilege escalation. This vulnerability threatens the stability and security of systems with Bluetooth RFCOMM enabled.
Recommendation
Apply the official kernel patch from the Linux repository immediately. Update to a kernel version containing the fix or backport the patch to your current kernel.
Original NVD description (English source)
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: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. 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().