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

CVE-2026-80819 Overview

CVE-2026-80819 is a NULL pointer dereference vulnerability in the Linux kernel's Bluetooth RFCOMM subsystem. The flaw resides in rfcomm_sock_recvmsg(), which completes a deferred setup by calling rfcomm_dlc_accept() without holding the rfcomm_mutex lock. A remote Bluetooth peer can send a DISC (disconnect) frame on a deferred RFCOMM data link connection (DLC), which clears d->session while leaving the RFCOMM_DEFER_SETUP bit set. A subsequent recv() on the accepted socket dereferences the NULL session pointer, causing a kernel oops. The condition is deterministic once the DISC has been processed and does not require a timing race.

Critical Impact
A local user with an accepted BT_DEFER_SETUP RFCOMM socket can trigger a kernel NULL pointer dereference in rfcomm_dlc_accept() when a remote Bluetooth peer sends a DISC frame, resulting in a denial-of-service kernel crash.

Affected Products

Linux kernel Bluetooth stack (net/bluetooth/rfcomm)
Multiple stable kernel branches referenced by fix commits 355bfd57, 362726c9, 43a556b2, 56f0aa75, 825b9556, b405c2f9, d4b1a13b, d8d686dd, and eb71d5a1
Systems with BR/EDR Bluetooth enabled and RFCOMM sockets in use

Discovery Timeline

2026-09-04 - CVE-2026-80819 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80819

Vulnerability Analysis

The vulnerability affects the RFCOMM protocol implementation in the Linux kernel Bluetooth stack. rfcomm_sock_recvmsg() handles deferred setup completion by invoking rfcomm_dlc_accept() without acquiring rfcomm_mutex. The first line of rfcomm_dlc_accept() dereferences d->session->sock->sk, assuming the session pointer is valid.

Every other code path that touches d->session runs under rfcomm_mutex, including rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). The recvmsg path is the only caller that skips this lock. This inconsistency creates an unsafe access pattern classified as a NULL pointer dereference [CWE-476].

Root Cause

The RFCOMM_DEFER_SETUP bit was assumed to serialize the accept against teardown because __rfcomm_dlc_close() returns early when it wins the test_and_clear. However, rfcomm_recv_disc() forces d->state = BT_CLOSED before calling __rfcomm_dlc_close(). The early-return switch only covers BT_CONNECT, BT_CONFIG, BT_OPEN, and BT_CONNECT2. With state already BT_CLOSED, the bit is never consulted and the code falls through to rfcomm_dlc_unlink(), which sets d->session = NULL while RFCOMM_DEFER_SETUP remains set.

Attack Vector

Exploitation requires a Bluetooth peer capable of establishing an L2CAP session on the RFCOMM PSM and opening a DLC on a channel bound with BT_DEFER_SETUP. After the local socket is accepted, the peer sends a DISC frame. When the local process calls recv() on the accepted socket, the kernel dereferences the cleared session pointer.

Reproduction on a KASAN and PROVE_LOCKING kernel using /dev/vhci produces the following kernel report:

Oops: general protection fault
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:rfcomm_dlc_accept+0x54/0x350
Call Trace:
  rfcomm_sock_recvmsg+0x1cd/0x230
  sock_recvmsg+0x166/0x1c0
  __sys_recvfrom+0x20d/0x300

Offset 0x10 corresponds to sock in struct rfcomm_session. The fix introduces an exported wrapper that takes rfcomm_mutex and re-checks the session before calling an internal __rfcomm_dlc_accept().

Detection Methods for CVE-2026-80819

Indicators of Compromise

Kernel oops messages referencing rfcomm_dlc_accept+0x54 or rfcomm_sock_recvmsg in dmesg or journalctl -k output
KASAN reports flagging null-ptr-deref in the RFCOMM code path
Unexpected kernel panics on systems with active Bluetooth BR/EDR connections

Detection Strategies

Monitor kernel logs for RFCOMM-related faults, general protection faults, or KASAN reports involving Bluetooth symbols
Audit running kernel version against the fixed commits published on git.kernel.org and flag hosts running unpatched Bluetooth-enabled kernels
Correlate Bluetooth pairing events with subsequent kernel instability on endpoints and IoT devices

Monitoring Recommendations

Enable and forward kernel crash telemetry (kdump, systemd-coredump, kernel ring buffer) to a central log store for analysis
Track Bluetooth service restarts and bluetoothd process anomalies on Linux endpoints
Alert on repeated RFCOMM socket errors or abnormal disconnect patterns from paired peers

How to Mitigate CVE-2026-80819

Immediate Actions Required

Apply the upstream kernel patch series referenced by commits 355bfd57, 362726c9, 43a556b2, 56f0aa75, 825b9556, b405c2f9, d4b1a13b, d8d686dd, and eb71d5a1 from git.kernel.org
Update to the latest stable kernel package supplied by your Linux distribution once it incorporates the fix
Inventory Linux hosts, workstations, and IoT devices that expose Bluetooth BR/EDR to identify exposure

Patch Information

The fix restructures rfcomm_dlc_accept() to mirror rfcomm_dlc_open() and rfcomm_dlc_close(). An exported wrapper acquires rfcomm_mutex and re-checks the session pointer, then delegates to an internal __rfcomm_dlc_accept() that in-tree callers already holding the mutex continue to use. Patch details are available in the Kernel.org RFCOMM fix commit and companion stable-tree backports.

Workarounds

Disable the Bluetooth service on systems that do not require it: systemctl disable --now bluetooth.service
Unload the rfcomm kernel module where feasible: modprobe -r rfcomm and blacklist it via /etc/modprobe.d/
Restrict Bluetooth pairing to trusted devices only and remove unused paired peers

bash

# Blacklist the RFCOMM kernel module
echo "blacklist rfcomm" | sudo tee /etc/modprobe.d/disable-rfcomm.conf
sudo modprobe -r rfcomm

# Disable Bluetooth service on hosts that do not need it
sudo systemctl disable --now bluetooth.service