CVE-2026-99091

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.