Description

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]

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-28T08:16:58.000Z",
  "pubdate": "2026-08-28T08:16:58.000Z",
  "executiveSummary": "The Linux kernel's mac80211 subsystem is susceptible to an out-of-bounds memory access vulnerability during the processing of S1G TWT (Target Wake Time) setup frames.\nThe vulnerability arises due to insufficient validation of the TWT parameter length in the ieee80211_process_rx_twt_action() function before these parameters are passed to driver-specific callbacks.\nThis flaw allows a remote attacker, capable of sending malformed S1G TWT action frames, to trigger an out-of-bounds read or potential memory corruption when the driver attempts to process the incomplete parameter block.\nThe impact includes potential kernel instability, system crashes (denial of service), or potential information disclosure depending on how the driver handles the undersized structure.\nExploitation requires the attacker to be within radio range to inject specifically crafted S1G TWT management frames.\nThe vulnerability affects systems implementing the mac80211 stack with S1G (Sub-1 GHz) TWT support enabled.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper sanitization of TWT (Target Wake Time) setup frames within the mac80211 networking stack. Specifically, the function ieee80211_process_rx_twt_action() performs only a superficial validation of incoming TWT setup frames before enqueuing them for further processing.\nWhen an individual TWT agreement frame is received, the validation logic fails to verify that the length of the TWT parameter block is sufficient to encapsulate the expected struct ieee80211_twt_params. Consequently, an agreement with an inadequate length is allowed to proceed to the function ieee80211_s1g_rx_twt_setup().\nOnce the flow reaches ieee80211_s1g_rx_twt_setup(), the kernel invokes drv_add_twt_setup(), which facilitates the interaction with the underlying wireless driver. The driver callback, as well as the associated tracepoints, assume that the provided TWT parameter structure is complete and of the expected size. Because the check was bypassed, the code attempts to access memory beyond the actual bounds of the received frame buffer.\nThe exploitation flow begins with the attacker injecting a malicious S1G TWT setup frame into the wireless medium. By crafting a frame where the length field indicates an insufficient payload, the attacker forces the mac80211 subsystem to treat truncated data as a valid struct ieee80211_twt_params. When the kernel or the driver hardware-specific backend attempts to read this memory, it triggers an out-of-bounds read.\nIf the driver-level implementation performs operations like copying the structure to hardware memory or dereferencing pointers based on the malformed fields, this could lead to memory corruption or undefined behavior. The vulnerability persists because the validation logic only performs a partial check, focusing on the req_type field while neglecting the integral data structure size requirements for individual agreements.\nThis issue is limited to individual TWT agreements; broadcast agreements remain unaffected because they are correctly rejected locally after inspecting only the req_type field, which serves as a sufficient guard for that specific case. The vulnerability underscores the danger of decoupling parameter validation from the structural requirements imposed by secondary driver callbacks."
}