---
id: "CVE-2026-99091"
kind: "vulnerability"
aliases: ["CVE-2026-99091"]
title: "Linux kernel: Bluetooth flushed commands report success instead of errors"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["bluetooth", "bluez", "infrastructure", "linux"]
not_affected_if: ["no-bluetooth-adapter"]
published_at: "2026-10-26T15:16:47+00:00"
first_seen_at: "2026-10-26T16:02:26+00:00"
updated_at: "2026-10-26T16:04:10+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99091", "first_seen_at": "2026-10-26T16:02:26+00:00"}]
---

# Linux kernel: Bluetooth flushed commands report success instead of errors

When the Bluetooth adapter is powered off, pending management commands such as Start Discovery are answered with status 0x00 (Success) instead of Not Powered or Invalid Index, because the wrong value is read from a pointer. The result is a wrong status to userspace, which can crash bluetoothd on a zero-length success reply.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Apply the upstream Linux kernel fix that passes the caller's status through cmd_complete_rsp (commit f53e1c9c726d follow-up), and update to a kernel release containing it.
- Update BlueZ to a release with the short start discovery reply length check (BlueZ a734b06059cb).

## Timeline

- 2026-10-26T16:02:26+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99091

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_