Cloudanix VulnDB

CVE-2026-68339

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the way Linux reads certain wireless messages from Realtek Bluetooth chips could cause connection problems or system hiccups when a nearby device sends unusual data.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Insufficient length validation in btusb_recv_event_realtek allows reading a nonexistent third byte from short Realtek vendor events before inspecting the subevent code, enabling out-of-bounds memory access and potential misclassification as a coredump.

Why it matters to the business

Linux systems using Realtek Bluetooth adapters may experience unexpected Bluetooth stack behavior, crashes, or degraded wireless connectivity, with low but nonzero risk of exploitation affecting device operations.

How an attack unfolds

An attacker pairs a malicious Bluetooth peripheral that emits a minimal two-byte vendor event (such as ff 00); the driver reads beyond the supplied data into adjacent memory and, when that byte matches 0x34, incorrectly routes the event as a coredump instead of normal HCI handling.

How to fix it

Apply the upstream kernel commit that requires both the HCI event header and first parameter to be present before inspecting the Realtek subevent code; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Inspect the btusb.c source for an explicit length check (HCI event header plus at least one parameter) preceding the data[2] access in btusb_recv_event_realtek; confirm the short-event path now falls through to normal HCI validation.

Typical attack path

  1. Establish a Bluetooth connection from a crafted peripheral
  2. Transmit a short Realtek vendor event lacking the declared parameter length
  3. Trigger btusb_recv_event_realtek to read data[2] without header validation
  4. Cause misclassification and subsequent incorrect event processing

How to detect it

Review kernel logs for Bluetooth event receive paths, unexpected coredump handling, or HCI protocol warnings; correlate with dmesg entries mentioning btusb or Realtek vendor events around the time of anomalies.

What your security team should do

  • Prioritize kernel updates containing the length-validation fix for all Realtek Bluetooth hosts
  • Monitor vendor firmware advisories for additional Realtek controller mitigations
  • Test Bluetooth functionality post-update to ensure normal event handling is restored

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.

Affected packages

Ecosystem Package Introduced Fixed