CVE-2026-90251 in Linux
Summary
by MITRE • 09/17/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel Bluetooth subsystem contains a validation flaw within the Microsoft vendor-specific feature handling logic that allows for the processing of malformed or maliciously crafted responses from Bluetooth controllers. Specifically, in the read_supported_features function, the code performs an initial check to ensure that the incoming response packet is at least large enough to contain the fixed portion of the msft_rp_read_supported_features structure, which consists of eleven bytes. However, this validation fails to account for the variable-length component known as evt_prefix_len, a field extracted directly from the controller's reply without further verification against the actual remaining length of the data buffer. This oversight creates a scenario where an attacker controlling the Bluetooth hardware or emulating one can specify an arbitrary event prefix length up to two hundred and fifty-five bytes, regardless of whether that much data is actually present in the response packet.
The technical consequence of this validation gap occurs when the kernel attempts to duplicate the evt_prefix array using kmemdup. Because the function relies solely on the unvalidated evt_prefix_len field provided by the controller, it proceeds to copy up to two hundred and fifty-five bytes from memory locations that lie beyond the end of the received packet payload. While standard Linux kernel networking buffers include a small amount of slack space allocated for shared information structures, which prevents this specific read operation from triggering an out-of-bounds access error or causing immediate memory corruption detectable by tools like KASAN, it still constitutes a serious logical vulnerability. The system reads uninitialized or stale data that was never intended to be part of the vendor event prefix definition, leading to incorrect state initialization within the Bluetooth stack.
This flaw poses significant operational risks related to integrity and potential future exploitation vectors. Although the immediate impact is limited to reading undefined memory contents rather than executing arbitrary code, the corrupted evt_prefix array is subsequently used in msft_vendor_evt to match incoming vendor-specific events. If an attacker can influence how these uninitialized bytes are interpreted or if subsequent logic relies on this data for decision-making, it could lead to incorrect event routing, denial of service through mismatched protocol states, or potentially serve as a primitive for more complex attacks such as information disclosure or heap spraying techniques in other contexts where similar patterns exist. The vulnerability aligns with CWE-20 Improper Input Validation and falls under the ATT&CK technique of Taint Analysis evasion by exploiting insufficient boundary checks on variable-length fields within structured protocol messages.
To mitigate this risk, developers must implement strict length validation that ensures the total response size is sufficient to contain both the fixed header and the declared variable-length prefix data before attempting any memory duplication operations. The fix involves rejecting responses where the actual packet length is less than the sum of the fixed structure size and the advertised evt_prefix_len value. This prevents the kernel from accessing memory beyond the intended payload boundary, ensuring that only valid, controller-provided data influences the Bluetooth stack's internal state management. System administrators should apply kernel updates that include this patch to maintain the integrity of Bluetooth vendor-specific event processing mechanisms.