CVE-2026-98600: Linux Kernel RFCOMM Buffer Overflow Vulnerability

CVE-2026-98600 is a buffer overflow flaw in the Linux kernel RFCOMM implementation that occurs when processing short EA=0 frames. This vulnerability allows malformed frames to bypass length validation. This article covers technical details, affected kernel versions, security impact, and available patches.

CVE-2026-98600 Overview

CVE-2026-98600 is a Linux kernel vulnerability in the Bluetooth RFCOMM subsystem. The flaw resides in rfcomm_recv_frame() where length validation does not account for RFCOMM frames carrying an extended two-byte length field (EA=0). A short four-byte frame with EA=0 bypasses the initial size check, and the subsequent skb_pull() call fails without advancing skb->data. The unparsed three-byte rfcomm_hdr is then processed as application payload or as a multiplexer control command on DLCI 0. The vulnerability was addressed through multiple stable-tree commits in the upstream Linux kernel.

Critical Impact
A remote Bluetooth peer within radio range can send a malformed RFCOMM frame that causes the kernel to process header bytes as user data or control commands, potentially leading to protocol state corruption or information disclosure.

Affected Products

Linux kernel versions containing the vulnerable rfcomm_recv_frame() logic in net/bluetooth/rfcomm/core.c
Linux distributions shipping unpatched Bluetooth RFCOMM support
Any system with Bluetooth enabled and the RFCOMM module loaded

Discovery Timeline

2026-10-18 - CVE-2026-98600 published to NVD
2026-10-19 - Last updated in NVD database

Technical Details for CVE-2026-98600

Vulnerability Analysis

The defect is an input validation error [CWE-20] in the RFCOMM frame receive path. RFCOMM headers include a one-byte length field when the extended-address bit (EA) is set, and a two-byte length field when EA=0. The existing check in rfcomm_recv_frame() enforces a minimum of sizeof(*hdr) + 1 bytes, which equals four bytes (three-byte header plus one-byte Frame Check Sequence). This minimum is insufficient for EA=0 frames, which require five bytes (four-byte header plus one-byte FCS).

When a four-byte EA=0 frame arrives, trimming the FCS reduces skb->len to three. The call to skb_pull(skb, 4) then fails because four exceeds three, returning NULL without advancing skb->data. The return value is not checked. The unmodified rfcomm_hdr bytes are then dispatched either to rfcomm_recv_data() as application payload or to rfcomm_recv_mcc() as a multiplexer control command on DLCI 0.

Root Cause

The root cause is an incomplete length precondition that fails to differentiate between EA=1 and EA=0 frame formats. The fix extends the length check to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len) is true, rejecting undersized extended-length frames before any pull or parse operation.

Attack Vector

Exploitation requires an attacker able to deliver a crafted RFCOMM frame to a target with Bluetooth enabled and a reachable RFCOMM endpoint. Because RFCOMM runs over L2CAP, a paired or in-range peer can submit the malformed frame. The resulting behavior causes raw header bytes to be interpreted as RFCOMM control data, which can corrupt session state, trigger unexpected multiplexer actions on DLCI 0, or expose header-derived information to higher layers.

No verified public proof-of-concept code is available. See the upstream fix in Linux Kernel Commit 6d91041b and the parallel stable backports for the exact patch logic.

Detection Methods for CVE-2026-98600

Indicators of Compromise

Unexpected RFCOMM multiplexer control messages on DLCI 0 originating from untrusted or newly paired devices
Kernel log entries from the bluetooth subsystem indicating malformed RFCOMM frames or unexpected disconnections during active sessions
Short L2CAP frames (four bytes payload) targeting the RFCOMM PSM from nearby devices

Detection Strategies

Capture Bluetooth HCI traffic with btmon or hcidump and inspect RFCOMM frames for EA=0 headers under five bytes total
Monitor kernel audit and dmesg output for anomalies in net/bluetooth/rfcomm on hosts that expose RFCOMM services
Review loaded kernel module versions against patched stable releases to identify unmitigated endpoints

Monitoring Recommendations

Centralize kernel and Bluetooth daemon logs for correlation across the fleet
Alert on repeated RFCOMM session teardowns or protocol errors from the same remote Bluetooth address
Track Bluetooth adapter state changes and new pairings on laptops and IoT endpoints

How to Mitigate CVE-2026-98600

Immediate Actions Required

Apply the upstream Linux kernel patch or the vendor-provided backport for the running kernel series
Disable Bluetooth on systems that do not require it, particularly servers and workstations without a business need for wireless peripherals
Unload the rfcomm kernel module where Bluetooth remains enabled but RFCOMM services are not used

Patch Information

The fix extends the length validation in rfcomm_recv_frame() to require at least sizeof(*hdr) + 2 bytes for frames with !__test_ea(hdr->len). Patch commits are available in the stable tree: Linux Kernel Commit 6d91041b, Linux Kernel Commit 71ccacde, Linux Kernel Commit 76876fd2, Linux Kernel Commit 7a1781a2, Linux Kernel Commit 9240fc1f, Linux Kernel Commit 97711b96, Linux Kernel Commit be00deee, and Linux Kernel Commit c25587fa.

Workarounds

Blacklist the rfcomm module via /etc/modprobe.d/ to prevent load on boot
Restrict Bluetooth discoverability and reject pairings from unknown devices through user-space policy
Reduce physical attack surface by disabling Bluetooth radios on fixed-location endpoints that do not require wireless peripherals

bash

# Prevent the vulnerable RFCOMM module from loading
echo 'blacklist rfcomm' | sudo tee /etc/modprobe.d/disable-rfcomm.conf
sudo rmmod rfcomm 2>/dev/null || true

# Disable Bluetooth entirely where not required
sudo systemctl disable --now bluetooth.service