CVE-2026-99091
Received Received - Intake

Bluetooth: MGMT: Incorrect Status in Powered-Off Commands

Vulnerability report for CVE-2026-99091, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-10-26

Last updated on: 2026-10-26

Assigner: kernel.org

Description

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-10-26
Last Modified
2026-10-26
Generated
2026-10-26
AI Q&A
2026-10-26
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Showing 13 associated CPEs
Vendor Product Version / Range
Linux Linux 6.12
Linux Linux 4883296505aa7e4863c6869b689afb6005633b23
Linux Linux f53e1c9c726d83092167f2226f32bd3b73f26c21
Linux Linux f53e1c9c726d83092167f2226f32bd3b73f26c21
Linux Linux f53e1c9c726d83092167f2226f32bd3b73f26c21
Linux Linux f53e1c9c726d83092167f2226f32bd3b73f26c21
Linux Linux 19b40ca62607cef78369549d1af091f2fd558931
Linux Linux 0cc47233af35fb5f10b5e6a027cb4ccd480caf9a
Linux Linux 8c3f7943a29145d8a2d8e24893762f7673323eae
Linux Linux 6.6.55
Linux Linux 6.1.120
Linux Linux 6.10.14
Linux Linux 6.11.3

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves Bluetooth management commands being incorrectly reported as successful when they should fail. When a Bluetooth adapter is powered off, pending commands like 'Start Discovery' are flushed but receive a status of 'Success' (0x00) instead of the correct error status like 'Not Powered' (0x0f). This happens because the code incorrectly reads status from the wrong memory location.

Detection Guidance

This vulnerability affects the Linux kernel's Bluetooth management subsystem. Detection requires checking kernel logs for Bluetooth-related errors or crashes, particularly during power-off events. Monitor for commands like 'Start Discovery' failing with unexpected success statuses. Use 'dmesg | grep -i bluetooth' or 'journalctl -k | grep -i bluetooth' to inspect kernel logs for anomalies.

Impact Analysis

This vulnerability can cause Bluetooth applications like BlueZ to crash when they receive an unexpected success status for a command that should have failed. For example, if a 'Start Discovery' command is pending when the adapter powers off, the application may crash upon receiving a zero-length success response.

Mitigation Strategies

Update the Linux kernel to a patched version containing the fix for CVE-2026-99091. If immediate patching is not possible, disable Bluetooth functionality temporarily or restrict Bluetooth operations until the update is applied. Monitor BlueZ and kernel updates for fixes.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-99091. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart