Description
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).
Published: 2026-10-18
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Apply patch
AI Analysis

Impact

A flaw in the Linux kernel's RFCOMM implementation fails to correctly validate the length of frames that use an extended two‑byte length field with EA==0. The kernel checks that the packet length is at least the size of the header plus one byte, but it does not enforce the additional byte required when EA is set to zero. As a result, a malformed 4‑byte frame can slip through the initial test. The subsequent processing trims the Frame Check Sequence byte, reducing the length to three bytes, and then attempts to pull four bytes from the buffer. Because the pull fails but its return value is ignored, the three‑byte frame header remains unprocessed in the socket buffer. If the checksum verification succeeds, the kernel may forward this incomplete header to user space either as payload data or as a multiplexer control command. This mishandling can lead to incorrect application behavior or, in the worst case, a kernel crash, effectively allowing a remote attacker to cause a denial of service through crafted Bluetooth packets.

Affected Systems

All Linux kernels that expose a Bluetooth RFCOMM interface are potentially vulnerable. Consumers of the kernel through any distribution that has not applied the patch for the described RFCOMM frame validation issue are at risk. The vulnerability affects the core kernel code that processes incoming RFCOMM frames, so any system running a kernel configuration with Bluetooth support may be impacted.

Risk and Exploitability

The vulnerability can be exercised by an attacker who can send a specially crafted short RFCOMM frame to the target system, which is typically achieved over an active Bluetooth connection. The attack vector is remote, requiring only Bluetooth proximity. Although the EPSS score is unavailable and the issue is not listed in the CISA KEV catalog, the potential for a denial of service and the non‑negligible likelihood of exploitation through a Bluetooth interface suggest a moderate risk. The lack of a publishable exploit in the public domain does not eliminate the possibility that attackers could trigger the flaw, especially given the simplicity of the packet manipulation required.

Generated by OpenCVE AI on October 18, 2026 at 18:35 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the RFCOMM frame length validation fix
  • If an immediate kernel update is not feasible, disable RFCOMM or block Bluetooth traffic via firewall or RFkill
  • Monitor system logs for abnormal short RFCOMM frames and apply further hardening such as limiting Bluetooth device visibility

Generated by OpenCVE AI on October 18, 2026 at 18:35 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 18 Oct 2026 19:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-129

Sun, 18 Oct 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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).
Title Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-18T15:19:12.864Z

Reserved: 2026-09-25T10:25:14.359Z

Link: CVE-2026-98600

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-18T16:17:12.707

Modified: 2026-10-18T16:17:12.707

Link: CVE-2026-98600

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-18T18:45:06Z

Weaknesses
  • CWE-119

    Improper Restriction of Operations within the Bounds of a Memory Buffer

  • CWE-129

    Improper Validation of Array Index