Cloudanix VulnDB

CVE-2026-98600

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Bluetooth component in Linux did not properly check the size of certain short messages, allowing bad data to slip through and be handled as if it were legitimate.

Exploitation
Adjacent Network
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The RFCOMM frame receiver performs an insufficient length check that passes for 4-byte frames with EA=0; after FCS trimming the subsequent skb_pull is ignored, leaving a 3-byte header in place so that rfcomm_recv_data or rfcomm_recv_mcc treats attacker-controlled bytes as valid payload or multiplexer commands.

Why it matters to the business

Bluetooth-enabled Linux systems remain exposed to malformed frames that can corrupt protocol state or deliver unexpected data to user-space applications until the kernel is updated.

How an attack unfolds

An attacker within Bluetooth radio range crafts a minimal 4-byte RFCOMM frame with EA=0, sends it over an established RFCOMM channel, and relies on the missing length validation to cause the kernel to queue or interpret the remaining bytes as application data or control commands.

How to fix it

Apply the upstream kernel patch that extends the length check in rfcomm_recv_frame to require at least sizeof(*hdr)+2 bytes when !__test_ea(hdr->len); rebuild and reboot with the corrected kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting rfcomm_recv_frame for the additional EA-dependent length test; recompile a test kernel without the check and verify the original 4-byte frame triggers the old behavior.

Typical attack path

  1. Establish or hijack a Bluetooth RFCOMM connection to the target
  2. Transmit a 4-byte frame whose length field has EA=0
  3. Bypass the initial skb length check and cause skb_pull to fail silently
  4. Trigger rfcomm_recv_data or rfcomm_recv_mcc on the unadjusted buffer
  5. Observe or exploit the resulting protocol misinterpretation

How to detect it

Review kernel Bluetooth logs and RFCOMM debug output for unexpected short frames or malformed DLCI-0 traffic; correlate with sudden protocol state resets or application data containing partial RFCOMM headers.

What your security team should do

  • Prioritize kernel updates on all Bluetooth-enabled Linux hosts within the next maintenance window
  • Disable RFCOMM or Bluetooth entirely on systems where it is not required
  • Monitor vendor advisories for backported fixes in distribution kernels

The record

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).

Affected packages

Ecosystem Package Introduced Fixed