Cloudanix VulnDB

CVE-2026-90251

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in how Linux handles certain Bluetooth controller replies can let the system read and use memory it was never supposed to see, which may interfere with Bluetooth functions or allow unexpected behavior.

Exploitation
Other
Attacker needs
None
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

The Linux kernel Bluetooth MSFT driver fails to validate evt_prefix_len against the actual skb response length before performing kmemdup of up to 255 bytes from the response buffer, allowing a controller-controlled length to copy bytes past the declared response data into the evt_prefix used for later vendor event matching.

Why it matters to the business

Systems relying on Bluetooth with MSFT extensions may experience incorrect event handling or kernel data exposure from skb slack space, potentially disrupting Bluetooth operations or enabling further attacks on affected Linux hosts.

How an attack unfolds

An attacker with the ability to emulate or compromise a Bluetooth controller (such as via /dev/vhci) sends a minimal 11-byte MSFT read_supported_features response declaring a large evt_prefix_len; the kernel copies uninitialized bytes beyond the response into evt_prefix, which is later used to match incoming events in msft_vendor_evt.

How to fix it

Apply the upstream kernel patch that adds an explicit length check rejecting responses where skb->len is insufficient for the declared evt_prefix_len and ensure evt_prefix remains unset on failure.

How to confirm the fix worked

Confirm the patched kernel rejects a crafted 11-byte response declaring evt_prefix_len=255 with the message "MSFT event prefix length mismatch" and does not copy beyond the response; verify via vhci emulation on a KASAN-enabled build.

Typical attack path

  1. Gain ability to emulate or control a Bluetooth controller response (local or via hardware)
  2. Trigger MSFT read_supported_features command from the host
  3. Reply with exactly 11 bytes and evt_prefix_len set to 255
  4. Kernel performs unchecked kmemdup into msft->evt_prefix
  5. Subsequent vendor events may match using the invalid prefix data

How to detect it

Search kernel logs for "MSFT supported features length mismatch" or "MSFT event prefix length mismatch"; inspect Bluetooth event handling paths and skb allocations around msft_rp_read_supported_features for anomalous prefix lengths.

What your security team should do

  • Prioritize patching Bluetooth-enabled Linux kernels that include the MSFT driver
  • Monitor for upstream stable releases containing the evt_prefix_len validation fix
  • Restrict untrusted Bluetooth controller emulation or attachment where possible
  • Review Bluetooth stack usage in high-risk or multi-tenant environments

The record

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.

Affected packages

Ecosystem Package Introduced Fixed