Cloudanix VulnDB

CVE-2026-99091

None

CVSS

—

EPSS

0.2%

Published

Oct 26, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux Bluetooth handling could send the wrong reply when turning the radio off, causing Bluetooth software to crash.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect status byte passed to cmd_status_rsp in Bluetooth MGMT power-off flush, causing success (0x00) instead of intended MGMT_STATUS_NOT_POWERED or INVALID_INDEX due to using socket pointer or NULL instead of status value.

Why it matters to the business

Bluetooth management daemons may crash on adapter power off events, leading to loss of Bluetooth functionality until restart.

How an attack unfolds

No active exploitation; the flaw manifests when pending MGMT commands like Start Discovery are flushed during power off, sending invalid success response that crashes bluetoothd.

How to fix it

Apply the kernel commit that passes the caller-provided status to cmd_status_rsp in mgmt_index_removed and __mgmt_power_off paths.

How to confirm the fix worked

Confirm power off with pending commands now yields MGMT_STATUS_NOT_POWERED (0x0f) instead of 0x00, and test with hci_vhci under held HCI Write Scan Enable.

Typical attack path

  1. Trigger power off while pending Bluetooth discovery command exists
  2. MGMT flushes command with incorrect status 0x00
  3. Userspace daemon receives malformed response and crashes

How to detect it

Inspect bluetoothd logs and kernel MGMT traces for zero-length success replies or status 0x00 on Start Discovery during power-off sequences.

What your security team should do

  • Patch affected kernels with the Bluetooth MGMT status fix
  • Update BlueZ userspace to include length checks on discovery replies
  • Monitor kernel Bluetooth logs for flush events during adapter power transitions

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix status of pending commands flushed on power off cmd_complete_rsp() receives a struct cmd_lookup and, for a pending command that has no cmd_complete callback, falls through to cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so the status sent comes from the first byte of match->sk's representation, not from match->mgmt_status. commit f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed") changed the callers' data from &status to &match and updated the cmd_complete branch to match->mgmt_status, but left the fall-through passing data unchanged. In mgmt_index_removed() match->sk is NULL, so every such command is answered with status 0x00 (Success) instead of MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too, unless a Set Powered command was pending: then settings_rsp() has stored that command's socket in match->sk, and the byte sent comes from the socket pointer. Either way the status the caller set, MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device is being unregistered), is lost. Pass the status the callers set. This was seen on a QCA9377 laptop: bluetoothd's Start Discovery, pending when the adapter was powered off, was answered with Command Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the zero-length success. BlueZ master has since added the length check on that path ("adapter: Fix crash on short start discovery reply", BlueZ a734b06059cb), but userspace should still be told Not Powered, not Success. Tested on Ubuntu 7.0.0-31 with a virtual controller (hci_vhci): power off is held in HCI Write Scan Enable while a Start Discovery is submitted, and the flush answers it with status 0x00 before this change and 0x0f (Not Powered) after.

Affected packages

Ecosystem Package Introduced Fixed