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

Bluetooth: MSFT: validate evt_prefix_len against the response length

read_supported_features() only checks that the response covers the fixed
part of struct msft_rp_read_supported_features, which is 11 bytes:

if (skb->len < sizeof(*rp)) {
bt_dev_err(hdev, "MSFT supported features length mismatch");
goto failed;
}

evt_prefix[] is a flexible array member and rp->evt_prefix_len is an
unvalidated u8 taken straight out of that response, so

msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len,
GFP_KERNEL);

copies up to 255 bytes from a reply that may have carried none of them.
What is copied is data the controller never sent, and it is then used to
match incoming vendor events in msft_vendor_evt().

This is not an out-of-bounds access. An skb data allocation always has
at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the
payload, which is more than the 255 byte maximum, so the read stays
inside the allocation and KASAN does not report it. It is still a read
of bytes the host was never given, with the length fully controlled by
the controller.

Reject a response that is too short for the prefix it declares.

Verified with an emulated controller over /dev/vhci on a KASAN kernel,
with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk
and btrtl do unconditionally. A reply of exactly 11 bytes declaring
evt_prefix_len = 255 reaches kmemdup and copies 255 bytes
("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since
the reply ends at the fixed part, all 255 come from past the end of the
response. No KASAN report is produced, as expected from the allocation
slack described above. With this patch the response is rejected with
"MSFT event prefix length mismatch" and msft->evt_prefix is left unset.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Kernel Information Disclosure
Action: Apply patch
AI Analysis

Impact

This flaw concerns the Bluetooth stack in the Linux kernel. When a Microsoft‑specific event response arrives, the driver incorrectly trusts a length byte in the payload that indicates the size of a flexible array. It copies up to 255 bytes from the payload regardless of the actual length of the data sent, resulting in the kernel reading bytes that were never transmitted by the controller. Because the copy operation stops before the end of the skb buffer, no out‑of‑bounds error is triggered, but the host reads stale kernel memory. The data is then used by the vendor event matching logic, potentially leaking kernel contents. This constitutes a kernel information‑disclosure vulnerability.

Affected Systems

The vulnerability affects the Linux kernel’s Bluetooth subsystem, specifically the Microsoft (MSFT) vendor extension used by various drivers such as btintel, btqca, btmtk, and btrtl. No specific kernel version numbers are provided; any kernel build containing the affected code is potentially affected. Remediation requires a kernel update that incorporates the patch that rejects responses with an inconsistent prefix length.

Risk and Exploitability

The CVSS score is not listed, and the EPSS score is below 1 %, indicating a low probability of exploitation currently. The flaw is not listed in the CISA KEV. Attackers would need to control the Bluetooth controller sending the crafted response to the host, implying a local attack with physical or remote over‑the‑air access to the device. The lack of detectable bounds errors means standard kernel hardening will not detect the issue, yet the presence of a vulnerability that leaks kernel data is a serious concern for systems that expose Bluetooth services.

Generated by OpenCVE AI on September 19, 2026 at 03:37 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the kernel to a version that contains the patch rejecting too‑short responses.
  • If Bluetooth service is required, disable or restrict the Bluetooth interface or use a firewall to block rogue controllers.
  • Monitor for anomalous Bluetooth traffic with tools such as atrace or btsnoop to flag suspicious packet lengths.

Generated by OpenCVE AI on September 19, 2026 at 03:37 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sat, 19 Sep 2026 04:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-20

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: if (skb->len < sizeof(*rp)) { bt_dev_err(hdev, "MSFT supported features length mismatch"); goto failed; } evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes ("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with "MSFT event prefix length mismatch" and msft->evt_prefix is left unset.
Title Bluetooth: MSFT: validate evt_prefix_len against the response length
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:07:52.066Z

Reserved: 2026-09-11T19:38:34.795Z

Link: CVE-2026-90251

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:21.350

Modified: 2026-09-17T17:17:21.350

Link: CVE-2026-90251

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T08:30:16Z

Weaknesses
  • CWE-119

    Improper Restriction of Operations within the Bounds of a Memory Buffer

  • CWE-20

    Improper Input Validation