CVE-2026-99091 - Vulnerability Details

- Bluetooth: MGMT: Fix status of pending commands flushed on power off

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.

Published: 2026-10-26

Score: n/a

EPSS: n/a

KEV: No

Impact:

Action:

Analysis

Impact

The bug occurs when a pending Bluetooth management command has no completion callback. The command response logic incorrectly interprets the socket pointer as a status byte, causing the adapter to report a success status (0x00) instead of the intended Not Powered or Invalid Index. This faulty status can lead to downstream crashes, as observed in BlueZ 5.72 when the zero‑length success response is processed. Hence, the flaw results in incorrect status reporting and an application crash.

Affected Systems

This defect appears in the Linux kernel’s Bluetooth management layer. The CNA lists only the Linux kernel, and no explicit version range is supplied, so all kernel builds that lack the commit that patches the bug are affected.

Risk and Exploitability

The CVSS and EPSS metrics are not provided. The flaw is triggered by a locally logged Bluetooth command that is still pending when the adapter is powered off or unregistered. Because the fault occurs in kernel space and requires a pending command, it does not represent a remote code execution vector but can cause denial of service or stability issues on affected systems. The lack of an EPSS score and absence from KEV indicates that exploitation is not widespread yet, yet the logic defect warrants patching.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`4883296505aa7e4863c6869b689afb6005633b23`	affected	< 44ce36c5789ac84e65de1e98c32db9a5ac04ed47
`f53e1c9c726d83092167f2226f32bd3b73f26c21`	affected	< 7ed7e038b520cf0dfa12d61c2caddb95e2f6922d
`f53e1c9c726d83092167f2226f32bd3b73f26c21`	affected	< ec227cddd13cd7ac9077d263a73473ac370a055d
`f53e1c9c726d83092167f2226f32bd3b73f26c21`	affected	< 07976405a3c71253e50533ee7b7a8b0dc16ab6ba
`f53e1c9c726d83092167f2226f32bd3b73f26c21`	affected	< 86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc
`19b40ca62607cef78369549d1af091f2fd558931`	affected	—
`0cc47233af35fb5f10b5e6a027cb4ccd480caf9a`	affected	—
`8c3f7943a29145d8a2d8e24893762f7673323eae`	affected	—
`6.6.55`	affected	< 6.6.160
`6.1.120`	affected	< 6.2
`6.10.14`	affected	< 6.11
`6.11.3`	affected	< 6.12

Linux

affected

Version	Status	Constraints
`6.12`	affected	—
`0`	unaffected	< 6.12
`6.6.160`	unaffected	≤ 6.6.*
`6.12.113`	unaffected	≤ 6.12.*
`6.18.57`	unaffected	≤ 6.18.*
`7.2.11`	unaffected	≤ 7.2.*
`7.3`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

100%

Version	Status	Scheme	Platform
`[4883296505aa7e4863c6869b689afb6005633b23,44ce36c5789ac84e65de1e98c32db9a5ac04ed47)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,7ed7e038b520cf0dfa12d61c2caddb95e2f6922d)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,ec227cddd13cd7ac9077d263a73473ac370a055d)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,07976405a3c71253e50533ee7b7a8b0dc16ab6ba)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc)`	affected	code_commit	—
`19b40ca62607cef78369549d1af091f2fd558931`	affected	code_commit	—
`0cc47233af35fb5f10b5e6a027cb4ccd480caf9a`	affected	code_commit	—
`8c3f7943a29145d8a2d8e24893762f7673323eae`	affected	code_commit	—
`[6.6.55,6.6.160)`	affected	semver	—
`[6.1.120,6.2)`	affected	generic	—
`[6.10.14,6.11)`	affected	generic	—
`[6.11.3,6.12)`	affected	generic	—

Linux

100%

Version	Status	Scheme	Platform
`6.12`	affected	generic	—
`[0,6.12)`	unaffected	generic	—
`[6.6.160,6.7.0)`	unaffected	semver	—
`[6.12.113,6.13.0)`	unaffected	semver	—
`[6.18.57,6.19.0)`	unaffected	semver	—
`[7.2.11,7.3.0)`	unaffected	semver	—
`[7.3,*)`	unaffected	generic	—

Linux

Linux Kernel

100%

Version	Status	Scheme	Platform
`[4883296505aa7e4863c6869b689afb6005633b23,44ce36c5789ac84e65de1e98c32db9a5ac04ed47)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,7ed7e038b520cf0dfa12d61c2caddb95e2f6922d)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,ec227cddd13cd7ac9077d263a73473ac370a055d)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,07976405a3c71253e50533ee7b7a8b0dc16ab6ba)`	affected	code_commit	—
`[f53e1c9c726d83092167f2226f32bd3b73f26c21,86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc)`	affected	code_commit	—
`19b40ca62607cef78369549d1af091f2fd558931`	affected	code_commit	—
`0cc47233af35fb5f10b5e6a027cb4ccd480caf9a`	affected	code_commit	—
`8c3f7943a29145d8a2d8e24893762f7673323eae`	affected	code_commit	—
`[6.6.55,6.6.160)`	affected	semver	—
`[6.1.120,6.2)`	affected	generic	—
`[6.10.14,6.11)`	affected	generic	—
`[6.11.3,6.12)`	affected	generic	—

Linux

Linux Kernel

100%

Version	Status	Scheme	Platform
`6.12`	affected	generic	—
`[0,6.12)`	unaffected	generic	—
`[6.6.160,6.7.0)`	unaffected	semver	—
`[6.12.113,6.13.0)`	unaffected	semver	—
`[6.18.57,6.19.0)`	unaffected	semver	—
`[7.2.11,7.3.0)`	unaffected	semver	—
`[7.3,*)`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

Upgrade the Linux kernel to a version that includes the commit f53e1c9c726d or later.
Restart the Bluetooth daemon (systemctl restart bluetooth) to load the updated kernel modules.
Monitor system logs for unexpected "Command Status 0x00" replies and verify that no crash messages appear after the update.

Generated by OpenCVE AI on October 26, 2026 at 17:06 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

No CVSS v3.1

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

No EPSS score available.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/07976405a3c71253e50533ee7b7a8b0dc16ab6ba
https://git.kernel.org/stable/c/44ce36c5789ac84e65de1e98c32db9a5ac04ed47
https://git.kernel.org/stable/c/7ed7e038b520cf0dfa12d61c2caddb95e2f6922d
https://git.kernel.org/stable/c/86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc
https://git.kernel.org/stable/c/ec227cddd13cd7ac9077d263a73473ac370a055d

History

Mon, 26 Oct 2026 17:45:00 +0000

Type	Values Removed	Values Added
First Time appeared		Linux linux
Vendors & Products		Linux linux

Mon, 26 Oct 2026 17:30:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-20

Mon, 26 Oct 2026 15:00:00 +0000

Type	Values Removed	Values Added
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.
Title		Bluetooth: MGMT: Fix status of pending commands flushed on power off
First Time appeared		Linux Linux linux Kernel
CPEs		cpe:2.3:o:linux:linux_kernel::::::::
Vendors & Products		Linux Linux linux Kernel
References		https://git.kernel.org/stable/c/07976405a3c71253e50533ee7b7a8b0dc16ab6ba https://git.kernel.org/stable/c/44ce36c5789ac84e65de1e98c32db9a5ac04ed47 https://git.kernel.org/stable/c/7ed7e038b520cf0dfa12d61c2caddb95e2f6922d https://git.kernel.org/stable/c/86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc https://git.kernel.org/stable/c/ec227cddd13cd7ac9077d263a73473ac370a055d

Subscriptions

Linux Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

Published: 2026-10-26T14:52:00.262Z

Updated: 2026-10-26T14:52:00.262Z

Reserved: 2026-09-25T10:25:14.390Z

Link: CVE-2026-99091

Vulnrichment

No data.

NVD

Status : Received

Published: 2026-10-26T15:16:47.960

Modified: 2026-10-26T15:16:47.960

Link: CVE-2026-99091

Redhat

No data.

OpenCVE Enrichment

Updated: 2026-10-26T17:30:15Z

Weaknesses

CWE-20
Improper Input Validation

Impact

Affected Systems

Risk and Exploitability

Tracking

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object