CVE-2026-53256: Linux Kernel Use-After-Free Vulnerability

CVE-2026-53256 Overview

CVE-2026-53256 is a use-after-free vulnerability in the Linux kernel's Bluetooth RFCOMM (Radio Frequency Communication) subsystem. The flaw resides in rfcomm_connect_ind() and the helper rfcomm_get_sock_by_channel(), which returns a listener socket without acquiring a reference before the list lock is released. A concurrent close on the listener can free the socket while rfcomm_connect_ind() is still using it, producing a slab-use-after-free condition detected by KASAN in lock_sock_nested(). The issue affects Bluetooth-enabled Linux systems and has been resolved upstream through multiple stable-tree backports.

Critical Impact
A race between an incoming RFCOMM connection and a listener socket close can free the parent listener while it is being used, enabling kernel memory corruption.

Affected Products

Linux kernel Bluetooth RFCOMM subsystem (net/bluetooth/rfcomm)
Multiple stable kernel branches receiving backports referenced in the kernel.org commits
Linux distributions shipping vulnerable kernel versions with Bluetooth enabled

Discovery Timeline

2026-06-25 - CVE-2026-53256 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53256

Vulnerability Analysis

The vulnerability is a classic reference-counting race condition in the Linux kernel's Bluetooth RFCOMM listener path. rfcomm_get_sock_by_channel() walks rfcomm_sk_list under rfcomm_sk_list.lock and selects a listener socket matching the incoming channel. After locating the candidate, the function drops the list lock and returns the socket pointer to the caller without incrementing its reference count.

The caller, rfcomm_connect_ind(), then calls lock_sock(parent), enqueues a child socket using bt_accept_enqueue(), reads parent socket flags, and may invoke sk_state_change() after unlocking. Between the time rfcomm_get_sock_by_channel() returns and the time rfcomm_connect_ind() finishes touching the parent, nothing prevents the listener from being torn down by a concurrent close().

Root Cause

The root cause is missing reference acquisition on the listener socket while it remains protected by rfcomm_sk_list.lock. When rfcomm_sock_release() enters via a parallel close(), it calls rfcomm_sock_shutdown() and rfcomm_sock_kill(), which unlinks and frees the parent socket. If the close path wins the race, the listener's memory is returned to the slab allocator before rfcomm_connect_ind() reaches lock_sock() or its deferred-setup callback, producing a use-after-free [CWE-416].

Attack Vector

Exploitation requires a local attacker capable of triggering Bluetooth RFCOMM listener creation and incoming connection indications concurrently with listener teardown. The attacker races a process that opens, listens, and closes RFCOMM sockets against incoming connection processing originating from the Bluetooth stack. A successful race corrupts kernel slab memory through dereference of the freed struct sock, which can lead to denial of service or, under controlled heap layouts, kernel memory disclosure or privilege escalation.

The upstream fix takes a reference on the listener before leaving rfcomm_sk_list.lock, rechecks BT_LISTEN state after lock_sock() succeeds, caches the deferred-setup bit while the parent is locked, and drops the reference after the last parent use. See the Kernel Git Commit 1f73f92 for the canonical patch.

Detection Methods for CVE-2026-53256

Indicators of Compromise

KASAN reports of slab-use-after-free in lock_sock_nested() invoked from rfcomm_connect_ind()
Freeing stack traces traversing rfcomm_sock_kill() and rfcomm_sock_release() immediately preceding the access
Unexpected kernel oops or panics in net/bluetooth/rfcomm/sock.c paths on systems with active Bluetooth

Detection Strategies

Enable KASAN on test and staging kernels to surface the race during fuzzing of RFCOMM socket APIs
Monitor dmesg and kernel crash collectors for stack traces referencing rfcomm_connect_ind, bt_accept_enqueue, or rfcomm_sock_kill
Inventory running kernel versions against the patched commits listed in the kernel.org references to identify unpatched hosts

Monitoring Recommendations

Centralize kernel logs and crash dumps to flag Bluetooth subsystem faults across the fleet
Audit which endpoints have the Bluetooth stack and rfcomm module loaded, since the issue is unreachable when RFCOMM is disabled
Track local user activity creating Bluetooth sockets in conjunction with kernel oops events as a correlated signal

How to Mitigate CVE-2026-53256

Immediate Actions Required

Apply the upstream stable kernel patches referenced under the CVE record, beginning with Kernel Git Commit 1f73f92 and the additional backports for affected branches
Update to a distribution kernel that incorporates the RFCOMM listener reference-count fix
Restrict local untrusted user access on multi-user systems where Bluetooth is enabled

Patch Information

The fix is distributed across several stable-tree commits, including Kernel Git Commit 43c441e, Kernel Git Commit 6f4462d, Kernel Git Commit 8802413, Kernel Git Commit a07d741, Kernel Git Commit b0e33e4, Kernel Git Commit de31973, and Kernel Git Commit f5ec76b. Each commit takes a reference on the listener socket before dropping rfcomm_sk_list.lock and releases it after the last use.

Workarounds

Disable the Bluetooth RFCOMM module on systems that do not require it by blacklisting rfcomm in /etc/modprobe.d/
Stop and mask the bluetooth service on servers where Bluetooth has no operational use
Limit local account access and apply seccomp or LSM policies to prevent untrusted users from creating Bluetooth sockets

bash

# Configuration example
# Blacklist the RFCOMM module to remove the vulnerable code path
echo "blacklist rfcomm" | sudo tee /etc/modprobe.d/disable-rfcomm.conf
sudo modprobe -r rfcomm

# Optionally disable the Bluetooth service entirely
sudo systemctl stop bluetooth.service
sudo systemctl mask bluetooth.service