CVE-2026-80722 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: validate individual TWT params before driver setup
ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it.
An individual agreement can therefore reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full struct ieee80211_twt_params.
The individual path passes twt to drv_add_twt_setup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely req_type. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only req_type.
[edit commit message to not overclaim lack of validation nor
understate driver impact]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in the Linux kernel within the mac80211 subsystem represents a critical input validation failure during the processing of Target Wake Time setup frames for S1G Wi-Fi devices. Specifically, the function ieee80211_process_rx_twt_action() is responsible for handling received TWT action frames but performs only partial validation before queuing them for further processing. This incomplete verification allows malformed or truncated individual agreement parameters to bypass initial checks and proceed deeper into the stack without ensuring that all required fields are present and correctly sized. The core issue lies in the assumption that incoming data structures will always conform to expected sizes, a dangerous premise when dealing with network packets from potentially untrusted sources.
The technical flaw manifests when an individual TWT agreement reaches ieee80211_s1g_rx_twt_setup() with the twt->length field indicating a size smaller than what is required for the full struct ieee80211_twt_params structure. Because subsequent operations, including tracepoint logging and driver callbacks via drv_add_twt_setup(), expect to access the complete parameters block rather than just the initial request type field, this discrepancy leads to out-of-bounds memory reads or writes. An attacker controlling the network traffic can craft a specially designed S1G TWT setup frame with an artificially short length value, thereby triggering undefined behavior within the kernel space when it attempts to dereference fields beyond the actual allocated buffer size.
From an operational impact perspective, this vulnerability poses significant risks including potential denial of service through system crashes or panics if the out-of-bounds access corrupts critical memory structures. In more severe scenarios, depending on how the kernel handles these invalid accesses and what data resides in adjacent memory regions, there is a theoretical possibility for information disclosure or even arbitrary code execution via heap corruption techniques. The vulnerability specifically affects individual agreements while broadcast agreements remain unaffected because they are rejected locally after accessing only the req_type field, which does not require reading beyond its immediate boundaries. This distinction highlights how inconsistent validation logic across different code paths can create exploitable gaps in security controls.
This issue aligns with CWE-20 Improper Input Validation and CWE-125 Out-of-bounds Read as defined by common weakness enumerations standards. The attack vector corresponds to ATT&CK technique T1498 Network Denial of Service, particularly when considering the potential for causing system instability through malformed packet injection. Mitigation strategies primarily involve applying vendor-provided kernel patches that enforce strict length checks before any driver interaction occurs. Administrators should ensure their systems are updated with the latest stable releases containing fixes for mac80211 validation logic. Additionally, implementing network-level intrusion detection systems capable of identifying anomalous S1G frame structures can provide an additional layer of defense against exploitation attempts targeting this specific kernel subsystem flaw.