CVE-2026-53256 Linux Kernel Bluetooth RFCOMM Use-After-Free

Technical summary

The vulnerability resides in rfcomm_connect_ind(), which calls rfcomm_get_sock_by_channel() to locate a listener socket for an incoming RFCOMM connection. The function returns a pointer to the listener after releasing the rfcomm_sk_list lock, but does not acquire a reference count on the socket. A concurrent close() operation can then execute rfcomm_sock_release() → rfcomm_sock_shutdown() → rfcomm_sock_kill(), freeing the listener before rfcomm_connect_ind() calls lock_sock() or bt_accept_enqueue(). The race window is narrow but exploitable: the listener can be deallocated between the unlock at step 2 and the lock_sock() call at step 3 in the connection path. The fix involves taking a reference on the listener before dropping rfcomm_sk_list.lock, rechecking the listener's BT_LISTEN state after acquiring the socket lock, caching the deferred-setup bit while the parent is locked, and releasing the reference after all parent uses complete. KASAN has detected this as a slab-use-after-free in lock_sock_nested().

Business impact

Successful exploitation could result in local kernel denial-of-service (crash/reboot) or potentially kernel code execution, depending on heap memory state and attacker capability. Systems providing Bluetooth services to multiple local users or running Bluetooth-connected IoT devices are at risk. The impact is magnified in containerized or virtualized environments where Bluetooth is exposed to guest users. Organizations relying on Bluetooth connectivity for critical device communication or authentication should prioritize patching to maintain availability and prevent privilege escalation.

Affected systems

The Linux kernel across all actively maintained stable branches is affected. The vulnerability impacts any system with Bluetooth RFCOMM support enabled (the module is commonly compiled as a module or built-in on desktop, laptop, and IoT distributions). Systems with Bluetooth disabled or kernel builds without RFCOMM support are not vulnerable. Specific kernel versions vary by distribution; verify your kernel version against the respective Linux vendor advisory for exact ranges and available patches.

Exploitability

Exploitation requires local access (AV:A in the CVSS vector), meaning the attacker must be authenticated on the system or have physical Bluetooth proximity. The low complexity (AC:L) and low privilege requirement (PR:L) indicate that once local access is obtained, triggering the race is straightforward: send a connection request while concurrently closing a listening socket. No user interaction is required. The race window is tight but reliably triggerable in controlled scenarios, making this a practical threat in multi-user or guest-facing systems. Public exploit proof-of-concept code would likely appear quickly after disclosure.

Remediation

Apply the kernel patch that implements proper reference counting for the listener socket in rfcomm_connect_ind(). The fix ensures the listener is pinned via refcount_inc() before rfcomm_sk_list.lock is released, the listener's state is rechecked after acquiring lock_sock(), and the reference is dropped only after all uses complete. Organizations must rebuild and redeploy kernels with the patch, or wait for their distribution vendor to provide patched kernel images. No userspace workaround exists; kernel-level patching is mandatory.

Patch guidance

Contact your Linux distribution vendor for patched kernel packages. Major distributions (Red Hat, Canonical, SUSE, Debian) will issue kernel updates through their respective security channels. Verify the patch commit hash or kernel version against the vendor advisory to confirm the fix is included. Test patched kernels in a non-production environment to ensure stability and compatibility with your Bluetooth stack before rolling out widely. Plan maintenance windows for kernel updates, as they typically require system reboot.

Detection guidance

Monitor system logs for kernel crashes or KASAN warnings mentioning 'rfcomm_connect_ind', 'lock_sock_nested', or 'slab-use-after-free'. Kernel dmesg logs will show 'BUG: KASAN: use-after-free' with a stack trace implicating the RFCOMM module. Enable CONFIG_KASAN in your kernel build if available for enhanced detection during pre-production testing. Intrusion detection systems with kernel event monitoring (e.g., via eBPF or kernel audit) can alert on abnormal Bluetooth socket state transitions. In production, runtime kernel integrity tools may detect exploitation attempts, though after-the-fact detection is inherently difficult for in-kernel race conditions.

Why prioritize this

This vulnerability scores HIGH (CVSS 8.0) due to the potential for kernel code execution combined with achievable local access requirements. Although it requires low-privilege local access and tight race timing, the impact (C:H, I:H, A:H) justifies immediate patching in any environment where multiple users access Bluetooth services or where untrusted guest access is possible. Organizations should prioritize patching production systems ahead of other non-critical kernel updates, particularly for devices in shared or IoT deployments.

Risk score, explained

The CVSS 3.1 score of 8.0 (HIGH) reflects: (1) attack vector of adjacent (Bluetooth proximity), (2) low complexity to trigger the race, (3) low privilege required for exploitation, (4) no user interaction needed, (5) scope unchanged (only the local system), and (6) confidentiality, integrity, and availability all rated HIGH due to potential kernel code execution or sustained denial-of-service. The score does not account for the current lack of KEV status or public exploits, which would further elevate real-world risk if those factors change.

Frequently asked questions