CVE-2026-98292 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct access
btmtksdio.c and btmtkuart.c cast a received WMT event straight to struct btmtk_hci_wmt_evt and read its op/flag fields without checking the event is long enough to contain them, unlike btmtk.c. The FUNC_CTRL case then further casts to struct btmtk_hci_wmt_evt_funcc and reads its 2-byte status field, again without a length check. Firmware that sends a short or malformed WMT event makes both drivers read past the end of the received SKB.
Mirror btmtk.c: validate the base WMT header with skb_pull_data() before touching any of its fields, and when a FUNC_CTRL event turns out to be the short, header-only form (a plain enable/disable ack with no status word), decode the result from the header's own flag byte instead (0 = success, otherwise failure).
Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel Bluetooth subsystem contains a critical out-of-bounds read vulnerability within the MediaTek SDIO and UART transport drivers, specifically in btmtksdio.c and btmtkuart.c. This flaw arises from an improper validation of data lengths before accessing structured memory fields associated with Wireless Management Transport (WMT) events. When these drivers receive WMT event packets from connected firmware devices such as MT7920, MT7921, MT7922, and MT7925 chipsets, they immediately cast the raw received data buffer directly to a struct btmtk_hci_wmt_evt structure. This casting operation assumes that the incoming packet contains at least enough bytes to represent the full header of this structure. However, unlike the reference implementation in btmtk.c which performs rigorous length checks prior to field access, these two drivers fail to verify whether the received socket buffer (SKB) is sufficiently long. Consequently, if a device firmware sends a short or malformed WMT event that does not meet the minimum size requirements of the target structure, the kernel proceeds to read memory beyond the allocated bounds of the packet data.
The operational impact of this vulnerability extends beyond simple information disclosure. By reading past the end of the received SKB, the driver accesses uninitialized or unrelated kernel memory. This behavior constitutes an out-of-bounds read that can lead to unpredictable system states depending on what data resides in the adjacent memory regions. In worst-case scenarios involving crafted malicious firmware responses, this could potentially be leveraged for information leakage, allowing an attacker with physical access to the hardware interface or control over the Bluetooth stack input to extract sensitive kernel memory contents. Furthermore, while primarily a read vulnerability, improper handling of malformed structures can sometimes lead to logic errors in subsequent processing steps that might affect system stability. The specific code path involves reading op and flag fields from the base structure, and for FUNC_CTRL events, further casting to struct btmtk_hci_wmt_evt_funcc to access a two-byte status field without ensuring the packet is long enough to contain this extended header.
From a classification perspective, this vulnerability aligns with CWE-125: Out-of-bounds Read, as it involves accessing memory locations outside of intended boundaries due to insufficient validation of input data length. It also relates to CWE-20: Improper Input Validation, since the core failure is the lack of checks on the size and integrity of incoming network or hardware packets before processing them as structured objects. In terms of attack vectors, this falls under ATT&CK technique T1608: Link Hijacking if exploited in a physical proximity context to manipulate Bluetooth connections, though the primary technical classification remains an input validation failure leading to memory safety violations. The vulnerability highlights a common pattern where developers assume packet structures are always well-formed based on protocol specifications, ignoring the reality that firmware implementations may vary or be compromised.
The resolution for this issue involves mirroring the robust implementation found in btmtk.c by introducing strict length validations before any structural casting occurs. Specifically, drivers must now use skb_pull_data() to validate and prepare the base WMT header data only after confirming it meets minimum size requirements. This ensures that subsequent field accesses are safe from out-of-bounds reads. Additionally, for FUNC_CTRL events, which can sometimes arrive as short headers containing only enable or disable acknowledgments without a status word, the fix implements logic to decode success or failure directly from the flag byte in the header rather than relying on a potentially non-existent extended structure. This approach ensures that even truncated packets are handled gracefully without causing memory violations. The patch has been verified across multiple MediaTek chipsets including MT7920 through MT7925, confirming no regression and restoring safe operation of Bluetooth interfaces dependent on these drivers. System administrators should apply kernel updates containing this fix to mitigate the risk associated with untrusted or compromised Bluetooth firmware interactions.