# CVE-2026-99091: linux: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: MGMT: Fix status of pending commands...

CVE-2026-99091 is fixed in linux on 1 platform, first by DEBIAN-CVE-2026-99091, released October 27, 2026. It is not reported as exploited. Patch Radar priority: Routine.

- Web page: https://patchblox.com/security/cve/CVE-2026-99091
- Priority: Routine
- CVSS: n/a
- EPSS: 0.0017
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Oct 26, 2026

## 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.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 13.5 (trixie) | 6.12.113-1 | [DEBIAN-CVE-2026-99091](https://patchblox.com/security/data/fix/linux/debian-cve-2026-99091.md) | Oct 27, 2026 |
| Linux | linux Debian 14 | 7.2.11-1 | [DEBIAN-CVE-2026-99091](https://patchblox.com/security/data/fix/linux/debian-cve-2026-99091.md) | Oct 27, 2026 |

---

Data as of 2026-11-09T07:25:28Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.