CVE-2026-98600 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()
While rfcomm_recv_frame() verifies that skb->len is at least sizeof(*hdr) + 1 (4 bytes: 3-byte header + 1-byte FCS), an RFCOMM frame with an extended 2-byte length field (!__test_ea(hdr->len)) has a 4-byte header plus a 1-byte FCS (5 bytes minimum, sizeof(*hdr) + 2).
When a 4-byte RFCOMM frame with EA == 0 arrives: 1. The initial skb->len < sizeof(*hdr) + 1 check passes (4 < 4 is false). 2. Trimming the FCS byte decrements skb->len to 3. 3. If __check_fcs() succeeds, skb_pull(skb, 4) fails (4 > 3) and returns NULL without advancing skb->data. 4. Because the return value of skb_pull() is ignored, the un-pulled 3-byte struct rfcomm_hdr remains at skb->data and is either queued as application payload via rfcomm_recv_data() or parsed as a multiplexer control command via rfcomm_recv_mcc() on DLCI 0.
Fix this by extending the length check in rfcomm_recv_frame() to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel Bluetooth subsystem contains a critical input validation flaw within the RFCOMM protocol implementation, specifically in the rfcomm_recv_frame function. This vulnerability arises from an insufficient length check that fails to account for the structural differences between standard and extended address frames. The Remote Control Protocol (RFCOMM) is built on top of the Logical Link Control and Adaptation Layer Protocol (L2CAP) and provides a serial-port-like interface over Bluetooth connections, making it essential for many legacy devices and services such as OBEX file transfer or modem dial-up networking. When an RFCOMM frame arrives, the kernel must validate its integrity before processing. The code correctly verifies that the socket buffer length is at least sufficient to hold a standard header plus one Frame Check Sequence byte. However, this validation logic does not adequately distinguish between frames with extended addressing and those without, leading to a boundary condition error when handling specific malformed packets.
The technical root cause lies in the disparity between frame formats defined by the RFCOMM specification. Standard frames utilize a single-byte length field where the most significant bit indicates whether an extended two-byte length format is used. If this Extended Addressing flag is set, the header structure expands to include additional bytes for addressing and potentially different padding or checksum requirements. The vulnerability occurs when a frame with EA equal to zero arrives but has a total size of exactly four bytes. In this scenario, the initial check passes because it expects at least four bytes for a standard header plus FCS. However, subsequent processing steps assume a minimum payload structure that requires five bytes if extended addressing logic is inadvertently triggered or misinterpreted during parsing. Specifically, after trimming the Frame Check Sequence byte, the remaining buffer length becomes insufficient to support the expected pull operation on the socket buffer data pointer.
This discrepancy leads to a dangerous state where the skb_pull function fails because it attempts to remove more bytes than are available in the buffer. Crucially, the return value of this failed memory manipulation is ignored by the calling code. As a result, the packet descriptor remains pointing at invalid or partially processed memory regions containing only three bytes of header data rather than the expected complete structure. This malformed state allows corrupted data to be passed further down the processing pipeline. The application layer may receive garbage as payload data through rfcomm_recv_data, potentially causing crashes in user-space applications that expect well-formed serial streams. Alternatively, if this occurs on DLCI zero, which handles multiplexer control commands, the kernel might interpret random bytes from the buffer as valid control instructions via rfcomm_recv_mcc.
The operational impact of this vulnerability is significant due to its potential for denial of service and arbitrary code execution. An attacker positioned within Bluetooth range can craft a malicious RFCOMM frame with EA set to zero but sized precisely at four bytes. Upon reception, the kernel's failure to properly validate the length against the extended format requirements results in memory corruption or logic errors. If interpreted as control commands on DLCI 0, this could allow an attacker to manipulate connection states, disrupt ongoing sessions, or potentially exploit subsequent parsing bugs that rely on predictable header structures. This represents a classic case of improper input validation leading to undefined behavior within kernel space, which can destabilize the entire system depending on how the corrupted data is subsequently handled by higher-level protocols or drivers.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-134 Use of Externally-Controlled Format String if the malformed data leads to formatting errors in logging or debugging outputs. In terms of attack vectors, it falls under ATT&CK technique T1569 System Services, specifically leveraging local exploitation through network protocol handlers that are exposed via Bluetooth interfaces. The vulnerability highlights the importance of rigorous boundary checking when dealing with variable-length structures common in networking protocols like RFCOMM where header sizes can change based on flags within the first byte itself.
To mitigate this risk, kernel maintainers have implemented a fix by extending the length check in rfcomm_recv_frame to explicitly require that skb->len is greater than or equal to sizeof(*hdr) plus two bytes when the extended addressing flag is not set but the frame size suggests otherwise. This ensures that the buffer contains sufficient data for all expected header components before any memory pointers are advanced. System administrators should apply kernel updates immediately to patch this flaw, as it affects a core component of Bluetooth connectivity in Linux distributions. Additionally, deploying intrusion detection systems capable of analyzing RFCOMM traffic patterns can help identify attempts to exploit this specific length mismatch condition by monitoring for unusually short frames with specific header configurations during active connections.