CVE-2026-90370 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config
The response TLV loop advanced by tlv->len without a minimum, so a theoretical firmware response containing a zero-length TLV could spin forever, hanging the CPU during device probe. The u32 payload was also read without bounds checking. Reject a short fixed field, stop on a TLV whose length underruns the header or overruns the skb.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's mt7996 wireless driver component represents a critical input validation failure within the management control unit interface handling logic. Specifically, the function responsible for retrieving chip configuration data via Type-Length-Value structures failed to enforce proper boundary checks during the parsing of firmware responses. This flaw allows an attacker with access to the device probe phase or the ability to influence firmware response packets to trigger a denial of service condition through resource exhaustion. The core technical issue lies in the loop mechanism that iterates over TLV elements, where the iterator advances solely based on the length field provided by the incoming data without verifying against minimum thresholds or maximum buffer limits.
In a standard operational scenario, the driver expects well-formed firmware responses containing valid Type-Length-Value structures. However, because the implementation did not validate that the length field was greater than zero before advancing the pointer, a maliciously crafted response containing a TLV with a zero-length value would cause the loop to spin indefinitely. This infinite loop consumes CPU cycles continuously, effectively hanging the processor and rendering the system unresponsive during the device initialization or probe sequence. Such behavior constitutes a classic denial of service vulnerability where local availability is compromised due to improper handling of external input data structures.
Beyond the infinite loop issue, the code also exhibited unsafe memory access patterns by reading u32 payload values without performing bounds checking against the available buffer size. This lack of validation means that if a TLV length field indicates more data than actually exists in the socket buffer or allocated memory region, the driver will read beyond valid boundaries. This can lead to out-of-bounds reads, potentially exposing sensitive kernel memory contents to user space through subsequent operations or causing unpredictable system behavior depending on what data is inadvertently accessed. The absence of checks for both underflow and overflow conditions relative to the header size further exacerbates the risk of memory corruption or information disclosure.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input which describes cases where input is copied into a buffer without verifying its length, leading to potential overflows. Additionally, the infinite loop resulting from unvalidated zero-length inputs corresponds closely to CWE-835 Loop with Unreachable Exit Condition commonly known as an infinite loop vulnerability. In terms of attack vectors and tactics, this flaw can be leveraged within the context of ATT&CK technique T1496 Resource Hijacking where resources such as CPU are consumed to degrade system performance or availability. The specific mechanism involves manipulating data structures during device initialization which falls under initial access or execution phases depending on how the malformed TLV is injected into the communication channel between firmware and driver.
The operational impact of this vulnerability extends beyond simple service disruption. During the critical device probe phase, a hung CPU prevents the wireless adapter from initializing correctly, thereby denying network connectivity to users relying on that hardware. In server or infrastructure environments where automated systems depend on consistent hardware initialization, such hangs can trigger cascading failures in orchestration tools expecting timely responses. Furthermore, if the out-of-bounds read exposes kernel memory contents containing cryptographic keys, session tokens, or other sensitive information, it could lead to secondary exploitation vectors involving data exfiltration and privilege escalation attempts by local users who gain access to these leaked values through side channels or subsequent debugging interfaces.
Mitigation strategies primarily involve applying the upstream Linux kernel patches that address this specific flaw in the mt7996 driver implementation. System administrators should ensure their systems are updated with the latest stable kernel versions containing fixes for wifi: mt7996 TLV parsing logic. For environments where immediate patching is not feasible, deploying network segmentation to restrict access to management interfaces and monitoring tools can reduce exposure to malformed firmware responses if such traffic originates from external sources. Additionally, enabling strict memory protection features like Kernel Page Table Isolation and enforcing SELinux or AppArmor policies can help contain the blast radius should an out-of-bounds read occur by limiting what processes can access kernel memory regions.
Developers maintaining similar drivers must adopt rigorous input validation practices when parsing binary protocols involving variable-length fields. Every length field extracted from untrusted data sources such as firmware responses, network packets, or user-supplied buffers must be validated against both minimum and maximum constraints before being used to calculate offsets or allocate resources. Implementing explicit checks for zero lengths prevents infinite loops while verifying that the total size of a TLV does not exceed the remaining buffer capacity prevents out-of-bounds memory access. Integrating static analysis tools configured to detect these specific patterns into continuous integration pipelines can help identify such vulnerabilities early in the development lifecycle before they reach production environments.