CVE-2026-89569: Linux Kernel RFCOMM Use-After-Free Vulnerability

CVE-2026-89569 Overview

CVE-2026-89569 is a use-after-free vulnerability in the Linux kernel's Bluetooth RFCOMM (Radio Frequency Communication) subsystem. The flaw exists in rfcomm_security_cfm(), which looks up a session on session_list and walks its Data Link Connection (DLC) list without holding rfcomm_mutex. A concurrent krfcommd teardown can free the session and its DLCs while the security confirmation callback is still traversing them. KASAN reported a slab-use-after-free read triggered from hci_encrypt_change_evt during Bluetooth encryption change handling. The condition is reachable from any host within Bluetooth radio range, making it an adjacent-network attack.

Critical Impact
An attacker within Bluetooth range can trigger memory corruption in the kernel by racing RFCOMM session teardown against encryption change events, potentially leading to privilege escalation, kernel information disclosure, or denial of service.

Affected Products

Linux kernel Bluetooth subsystem (RFCOMM protocol implementation)
Distributions shipping kernels prior to the fix commits referenced in the mainline and stable trees
Any Linux-based system with Bluetooth enabled and RFCOMM in use (for example, hands-free profiles, Serial Port Profile)

Discovery Timeline

2026-09-11 - CVE-2026-89569 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-89569

Vulnerability Analysis

The vulnerability is a race condition producing a use-after-free in the RFCOMM security confirmation path. When the Host Controller Interface (HCI) receives an encryption change event, hci_rx_work dispatches hci_encrypt_cfm(), which invokes rfcomm_security_cfm(). That callback retrieves an RFCOMM session via rfcomm_session_get() and then iterates the session's DLC list without acquiring rfcomm_mutex.

RFCOMM session lifetime is otherwise governed by rfcomm_mutex. The krfcommd kernel thread can hold that mutex while calling rfcomm_session_close(), which unlinks DLCs via rfcomm_dlc_unlink() and frees the session with rfcomm_session_del() and kfree(s). Because the security confirmation callback does not participate in the mutex protocol, it can read a freed list_head and dereference freed DLC objects while updating their flags or timers.

Root Cause

Inconsistent locking discipline is the root cause. The RFCOMM subsystem enforces rfcomm_mutex for session and DLC teardown, but rfcomm_security_cfm() performs session lookup and DLC traversal without it. This TOCTOU-style gap allows the teardown path to invalidate the objects that the callback is actively touching. The fix serializes the callback with rfcomm_mutex, matching the existing lifetime rules.

Attack Vector

Exploitation requires an adjacent-network position over Bluetooth. An attacker must be able to establish or influence an RFCOMM session with the victim and trigger encryption change events at a time when the local session is being torn down. Successful racing of the two code paths yields a kernel use-after-free reachable from unauthenticated Bluetooth peers within radio range.

No public proof-of-concept exploit is currently available. Refer to the upstream fix commits for the precise code path: Kernel Git Commit 1b7841f and Kernel Git Commit 3873f34.

Detection Methods for CVE-2026-89569

Indicators of Compromise

KASAN reports of slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 in kernel logs
Unexpected kernel panics or oops entries referencing hci_rx_work, hci_encrypt_cfm, or rfcomm_security_cfm
Repeated Bluetooth link encryption changes from unknown or untrusted peers preceding kernel instability

Detection Strategies

Enable KASAN in test and staging kernels to surface memory-safety violations in the RFCOMM path
Monitor dmesg and journalctl -k for stack traces containing rfcomm_security_cfm or rfcomm_session_del
Correlate Bluetooth pairing and encryption change events with kernel crash telemetry across the fleet

Monitoring Recommendations

Ingest kernel logs into a centralized analytics platform and alert on RFCOMM or KASAN stack traces
Track kernel version and Bluetooth module state across endpoints to identify unpatched hosts
Baseline Bluetooth adapter activity so anomalous inbound RFCOMM connection attempts are surfaced quickly

How to Mitigate CVE-2026-89569

Immediate Actions Required

Apply the upstream Linux kernel fix or your distribution's backported update as soon as it is available
On systems that do not require Bluetooth, disable the Bluetooth service and unload the bluetooth and rfcomm kernel modules
Restrict Bluetooth discoverability and pairing to trusted devices only, reducing exposure to adjacent attackers

Patch Information

The issue is resolved by serializing session lookup and DLC traversal inside rfcomm_security_cfm() with rfcomm_mutex. Backports are available across stable branches. See the mainline and stable commits: Kernel Git Commit 62ce8b3, Kernel Git Commit 759c185, Kernel Git Commit 7ded326, Kernel Git Commit 82425b1, Kernel Git Commit 946d76d, and Kernel Git Commit fbf7961.

Workarounds

Disable Bluetooth entirely on systems that do not require it by stopping and masking the bluetooth.service unit
Blacklist the rfcomm kernel module to prevent RFCOMM sessions from being established
Enforce Bluetooth policy via MDM or configuration management to keep adapters powered off outside of business need

bash

# Disable Bluetooth service and blacklist RFCOMM module
sudo systemctl stop bluetooth.service
sudo systemctl mask bluetooth.service
echo 'blacklist rfcomm' | sudo tee /etc/modprobe.d/blacklist-rfcomm.conf
sudo rmmod rfcomm 2>/dev/null || true