Cloudanix VulnDB

CVE-2026-80760

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's Bluetooth code lets specially crafted commands confuse the wireless hardware, which could make Bluetooth connections unreliable until the system is updated.

Exploitation
Local Privilege
Attacker needs
High 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 mgmt_hci_cmd_sync handler accepts a __le16 params_len without upper-bounding it to 255, then copies the value into the single-byte plen field of an hci_command_hdr; the excess bytes remain in the skb, producing an HCI frame whose declared length mismatches its actual payload and that can desynchronize length-framed transports.

Why it matters to the business

Bluetooth controllers may receive corrupted command streams, leading to device instability, dropped connections, or unexpected behavior on systems using the Linux Bluetooth stack.

How an attack unfolds

An attacker with access to the Bluetooth management socket crafts an HCI_CMD_SYNC message whose params_len exceeds 255, causing the kernel to emit a malformed HCI command frame that the controller interprets incorrectly or that shifts subsequent packet boundaries on H:4 transports.

How to fix it

Apply the upstream fix that rejects params_len values larger than 255 in mgmt_hci_cmd_sync; rebuild and deploy an updated Linux kernel containing commit 03f1700b9b4d plus the additional length check.

How to confirm the fix worked

Confirm the patched kernel source contains the explicit params_len > 255 rejection; test by attempting to submit an oversized HCI_CMD_SYNC via mgmt and verify the command is now rejected before reaching the HCI layer.

Typical attack path

  1. Obtain write access to the Bluetooth MGMT socket (normally requires CAP_NET_ADMIN or root).
  2. Send a crafted HCI_CMD_SYNC request with params_len greater than 255.
  3. Kernel emits an HCI command whose plen is truncated while the full payload is still present.
  4. Controller or transport layer misinterprets the frame, causing desynchronization or undefined behavior.

How to detect it

Review kernel logs for Bluetooth MGMT or HCI errors around the time of unexpected controller resets; look for processes issuing unusual numbers of HCI commands via the mgmt socket.

What your security team should do

  • Prioritize kernel updates for any system exposing the Bluetooth MGMT interface.
  • Restrict access to /dev/rfkill and the mgmt socket to the minimum required processes.
  • Monitor for future Bluetooth-related kernel advisories given the low but non-zero EPSS score.

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255 mgmt_hci_cmd_sync() checks that the message length agrees with params_len but puts no upper bound on it. params_len is __le16 while the parameter length in the HCI command header is a u8: struct hci_command_hdr { __le16 opcode; __u8 plen; } __packed; hci_cmd_sync_alloc() assigns one to the other: hdr->plen = plen; if (plen) skb_put_data(skb, param, plen); so a params_len of 256 leaves plen at 0 while all 256 bytes are still appended. The frame handed to the driver then declares no parameters and carries 256 of them. On a length framed transport such as H:4 the controller takes the trailing bytes as the start of the next packet. The mgmt socket MTU is HCI_MAX_FRAME_SIZE, so params_len can reach about 1KB this way. Commit 03f1700b9b4d ("Bluetooth: MGMT: reject malformed HCI_CMD_SYNC commands") only made params_len agree with the message length, a value that fits the message but not the header field is still accepted. Reject params_len that does not fit the header field.

Affected packages

Ecosystem Package Introduced Fixed