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().
Published: 2026-06-25
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

Based on the description, a race condition in the Linux kernel’s Bluetooth RFCOMM implementation allows a hostile peer to close a listener socket while an accept request is in flight. This results in a use‑after‑free that can corrupt kernel memory and may lead to privilege escalation, arbitrary code execution, or denial of service. The likely attack vector is an attacker establishing a remote Bluetooth connection and initiating an RFCOMM session during the race. The weakness is a classic use‑after‑free fault (CWE‑416).

Affected Systems

All Linux kernel installations that have not applied the current patch for CVE‑2026‑53256 are affected. No specific kernel version list is available in the CVE data, so any kernel that implements the RFCOMM participant socket list can be impacted unless the fix has already been merged.

Risk and Exploitability

The likely attack vector involves an attacker establishing an active Bluetooth connection to the vulnerable device and attempting to initiate an RFCOMM connection while simultaneously sending a close command to a listener socket. The exploit requires an active Bluetooth connection and the ability to initiate an RFCOMM connection while a peer cancels a listening socket. No EPSS or KEV data is available, and a CVSS score is not supplied, so the exact likelihood of exploitation in the wild is unknown. However, use‑after‑free bugs in kernel code are generally considered high severity, and the lack of a publicly available exploit does not eliminate the risk of an attacker discovering or crafting one.

Generated by OpenCVE AI on June 25, 2026 at 12:05 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a release that includes the CVE‑2026‑53256 fix
  • If an upgrade cannot be performed immediately, disable the Bluetooth RFCOMM listener service or the entire Bluetooth stack until the official patch is available
  • Continuously monitor vendor advisories and kernel changelogs for the patch release and apply it promptly when it appears

Generated by OpenCVE AI on June 25, 2026 at 12:05 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 25 Jun 2026 12:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Thu, 25 Jun 2026 09:15:00 +0000

Type Values Removed Values Added
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().
Title Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-25T08:39:46.591Z

Reserved: 2026-06-09T07:44:35.394Z

Link: CVE-2026-53256

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-25T12:15:03Z

Weaknesses