GHSA-75M9-VH6C-66MX

Vulnerability from github – Published: 2026-10-26 15:34 – Updated: 2026-10-30 15:34
VLAI
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-99091"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-26T15:16:47Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix status of pending commands flushed on power off\n\ncmd_complete_rsp() receives a struct cmd_lookup and, for a pending\ncommand that has no cmd_complete callback, falls through to\ncmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so\nthe status sent comes from the first byte of match-\u003esk\u0027s\nrepresentation, not from match-\u003emgmt_status.\n\ncommit f53e1c9c726d (\"Bluetooth: MGMT: Fix possible crash on\nmgmt_index_removed\") changed the callers\u0027 data from \u0026status to \u0026match\nand updated the cmd_complete branch to match-\u003emgmt_status, but left\nthe fall-through passing data unchanged.\n\nIn mgmt_index_removed() match-\u003esk is NULL, so every such command is\nanswered with status 0x00 (Success) instead of\nMGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too,\nunless a Set Powered command was pending: then settings_rsp() has\nstored that command\u0027s socket in match-\u003esk, and the byte sent comes\nfrom the socket pointer. Either way the status the caller set,\nMGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device\nis being unregistered), is lost.\n\nPass the status the callers set.\n\nThis was seen on a QCA9377 laptop: bluetoothd\u0027s Start Discovery,\npending when the adapter was powered off, was answered with Command\nStatus 0x00 and no parameters, and bluetoothd 5.72 crashed on the\nzero-length success. BlueZ master has since added the length check\non that path (\"adapter: Fix crash on short start discovery reply\",\nBlueZ a734b06059cb), but userspace should still be told Not Powered,\nnot Success.\n\nTested on Ubuntu 7.0.0-31 with a virtual controller (hci_vhci):\npower off is held in HCI Write Scan Enable while a Start Discovery is\nsubmitted, and the flush answers it with status 0x00 before this\nchange and 0x0f (Not Powered) after.",
  "id": "GHSA-75m9-vh6c-66mx",
  "modified": "2026-10-30T15:34:18Z",
  "published": "2026-10-26T15:34:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99091"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07976405a3c71253e50533ee7b7a8b0dc16ab6ba"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/44ce36c5789ac84e65de1e98c32db9a5ac04ed47"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7ed7e038b520cf0dfa12d61c2caddb95e2f6922d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/86ef0f58bdecdedb3a1240971c56d71b7e4ce3fc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bbc485ee811a74fc1d4733d0a2b0eb5aeb271a08"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec227cddd13cd7ac9077d263a73473ac370a055d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.