Answer in brief
CVE-2026-64549 records a Unknown severity vulnerability in Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-64549 records a Unknown severity vulnerability in Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <1813add71e386f77b3040e6c8dc9b7b3ff965a6c || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <bd56c23f1f8681a2857ee924a8bd3abf87c8913b || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <7a64f39ebe1bacd9004a62eceadac0b122ec3cc2 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <f80b4afe893dffa9fabdbf80fb4d6782b24a6793 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <4b4008dda1d0c6e598d7865631ad4eda63a560f0 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <bfc9e7be289df11e8e38c98cd78019d67fdd0bd5 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <a8e169d308775039200bb9c905c7ce420db6e8c5 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <dd068ef044128db655f48323a4acfd5907e04903 | 1813add71e386f77b3040e6c8dc9b7b3ff965a6c, bd56c23f1f8681a2857ee924a8bd3abf87c8913b, 7a64f39ebe1bacd9004a62eceadac0b122ec3cc2, f80b4afe893dffa9fabdbf80fb4d6782b24a6793, 4b4008dda1d0c6e598d7865631ad4eda63a560f0, bfc9e7be289df11e8e38c98cd78019d67fdd0bd5, a8e169d308775039200bb9c905c7ce420db6e8c5, dd068ef044128db655f48323a4acfd5907e04903 |
| Linux/Linuxgeneric | 4.4 | Not reported |
Published upstream
Jul 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 17, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <1813add71e386f77b3040e6c8dc9b7b3ff965a6c || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <bd56c23f1f8681a2857ee924a8bd3abf87c8913b || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <7a64f39ebe1bacd9004a62eceadac0b122ec3cc2 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <f80b4afe893dffa9fabdbf80fb4d6782b24a6793 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <4b4008dda1d0c6e598d7865631ad4eda63a560f0 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <bfc9e7be289df11e8e38c98cd78019d67fdd0bd5 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <a8e169d308775039200bb9c905c7ce420db6e8c5 || >=ddd68ec8f4847b460c9f580076eafe13b031a6fd <dd068ef044128db655f48323a4acfd5907e04903 | 1813add71e386f77b3040e6c8dc9b7b3ff965a6c, bd56c23f1f8681a2857ee924a8bd3abf87c8913b, 7a64f39ebe1bacd9004a62eceadac0b122ec3cc2, f80b4afe893dffa9fabdbf80fb4d6782b24a6793, 4b4008dda1d0c6e598d7865631ad4eda63a560f0, bfc9e7be289df11e8e38c98cd78019d67fdd0bd5, a8e169d308775039200bb9c905c7ce420db6e8c5, dd068ef044128db655f48323a4acfd5907e04903 |
| Linux/Linuxgeneric | 4.4 | Not reported |
Published upstream
Jul 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 17, 2026
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.
Quoted source text, attributed separately from HOL analysis.