CVE-2026-53256

Analyzed Analyzed - Analysis Complete

Use-After-Free in Linux Kernel Bluetooth RFCOMM

Publication date: 2026-06-25

Last updated on: 2026-07-08

Assigner: kernel.org

Description

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().

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-06-25

Last Modified

2026-07-08

Generated

2026-07-15

AI Q&A

2026-06-25

EPSS Evaluated

2026-07-14

NVD

CVE-2026-53256

EUVD

EUVD-2026-39207

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	2.6.12
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	From 5.16 (inc) to 6.1.176 (exc)
linux	linux_kernel	From 6.2 (inc) to 6.6.143 (exc)
linux	linux_kernel	From 5.11 (inc) to 5.15.210 (exc)
linux	linux_kernel	From 6.13 (inc) to 6.18.36 (exc)
linux	linux_kernel	From 6.7 (inc) to 6.12.94 (exc)
linux	linux_kernel	From 6.19 (inc) to 7.0.13 (exc)
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	From 2.6.12.1 (inc) to 5.10.259 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-416	The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Attack-Flow Graph

Executive Summary

This vulnerability exists in the Linux kernel's Bluetooth RFCOMM implementation. Specifically, the function rfcomm_get_sock_by_channel() scans a list of sockets under a lock but returns a listener socket after releasing that lock without taking a reference to it. Subsequently, rfcomm_connect_ind() locks the listener, queues a child socket, and may notify it after unlocking. However, a race condition can occur if the listener socket is closed and freed by another process before rfcomm_connect_ind() finishes its operations, leading to a use-after-free scenario.

The problem arises because rfcomm_connect_ind() does not hold a reference to the listener socket after dropping the list lock, allowing the listener to be freed concurrently. This can cause memory corruption or crashes when the freed listener is accessed. The fix involves taking a reference on the listener before releasing the list lock and rechecking its state after locking it to ensure it is still valid before proceeding.

Impact Analysis

This vulnerability can lead to a use-after-free condition in the Bluetooth RFCOMM code of the Linux kernel. Exploiting this could cause system instability, crashes, or potentially allow an attacker to execute arbitrary code or cause denial of service by triggering the race condition that frees and then accesses the listener socket.

Mitigation Strategies

The vulnerability has been resolved by taking a reference on the listener before leaving rfcomm_sk_list.lock, rechecking that it is still in BT_LISTEN after lock_sock() succeeds, caching the deferred-setup bit while the parent is locked, and dropping the reference after the last parent use.

Therefore, immediate mitigation involves updating the Linux kernel to a version that includes this fix to prevent use-after-free conditions in the Bluetooth RFCOMM code.

Hi! I’m here to help you understand CVE-2026-53256. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70