GHSA-4PQ4-7M8R-FRPC

Vulnerability from github – Published: 2026-07-27 21:31 – Updated: 2026-07-27 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()

bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at skb->data + 1, without checking the length:

bt_dev_info(hdev, "%s", (char *)(skb->data + 1));
hci_set_fw_info(hdev, "%s", skb->data + 1);

A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file.

Print the revision string with a bounded "%.*s" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-64549"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T21:17:07Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()\n\nbpa10x_setup() sends the vendor command 0xfc0e and passes the response\nto bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at\nskb-\u003edata + 1, without checking the length:\n\n\tbt_dev_info(hdev, \"%s\", (char *)(skb-\u003edata + 1));\n\thci_set_fw_info(hdev, \"%s\", skb-\u003edata + 1);\n\nA device that returns a one-byte response (status only) leaves\nskb-\u003edata + 1 past the end of the data, and the %s walk reads adjacent\nslab memory until it meets a NUL. The same happens when the payload is\nnot NUL-terminated within skb-\u003elen. The out-of-bounds bytes end up in\nthe kernel log and the firmware-info debugfs file.\n\nPrint the revision string with a bounded \"%.*s\" limited to skb-\u003elen - 1\ninstead. This keeps the string readable for well-behaved devices while\nnever reading past the received data, and does not fail setup, so a\ndevice returning a short or unterminated response keeps working.",
  "id": "GHSA-4pq4-7m8r-frpc",
  "modified": "2026-07-27T21:31:26Z",
  "published": "2026-07-27T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64549"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1813add71e386f77b3040e6c8dc9b7b3ff965a6c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4b4008dda1d0c6e598d7865631ad4eda63a560f0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7a64f39ebe1bacd9004a62eceadac0b122ec3cc2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a8e169d308775039200bb9c905c7ce420db6e8c5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bd56c23f1f8681a2857ee924a8bd3abf87c8913b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bfc9e7be289df11e8e38c98cd78019d67fdd0bd5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dd068ef044128db655f48323a4acfd5907e04903"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f80b4afe893dffa9fabdbf80fb4d6782b24a6793"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.