Description

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath11k_dp_rx_h_undecap_nwifi() function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially result in invalid data access and memory corruption. Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k] Call trace: ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k] ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k] ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k] ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k] ath11k_dp_service_srng+0x2e0/0x348 [ath11k] Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DP_RX_DECAP_TYPE_NATIVE_WIFI decap type. This adapted from the discussion/patch of the ath12k driver [1]. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-24T17:17:22.433Z",
  "pubdate": "2026-09-24T17:17:22.433Z",
  "executiveSummary": "A memory safety vulnerability exists in the ath11k driver's data path processing, specifically within the RX handling of native Wi-Fi frames.\nThe vulnerability is classified as an out-of-bounds memory access issue, leading to kernel stack corruption.\nThis flaw affects the ath11k wireless driver in the Linux kernel when operating with DP_RX_DECAP_TYPE_NATIVE_WIFI encapsulation.\nAn attacker capable of crafting specific ingress wireless frames can trigger this vulnerability when the hardware provides packets with lengths exceeding expected header thresholds.\nSuccessful exploitation results in kernel memory corruption, which can lead to system instability, denial of service (system crash), or potentially arbitrary code execution if the attacker successfully controls the memory layout.\nThe vulnerability is reachable via the Data Path (DP) RX processing pipeline during normal network operation, requiring no specific user authentication from the attacker, though it necessitates physical proximity to the wireless radio interface.",
  "technicalDetails": "The root cause of the vulnerability lies in an insufficient boundary check within the function ath11k_dp_rx_h_undecap_nwifi(). The driver fails to validate that the incoming SKB (socket buffer) length is compatible with the maximum native Wi-Fi header length before performing read and write operations on the header fields.\nWhen the hardware provides a packet where the length exceeds the expected threshold for native Wi-Fi frames, the ath11k_dp_rx_h_undecap_nwifi() function proceeds to access header fields based on assumed offsets. Because the length constraint is not enforced, this results in an out-of-bounds memory access. The subsequent write operations modify memory locations beyond the intended header buffer, which impacts the kernel stack, as evidenced by the provided call trace originating from ath11k_dp_rx_h_mpdu.\nThe attack flow begins with the arrival of a malicious or malformed wireless frame received by the WCN6855 hardware. As the driver processes the frame through the RX path—specifically via ath11k_dp_service_srng and ath11k_dp_rx_process_wbm_err—it reaches the undecapilation logic. The lack of length validation allows the driver to treat data outside the valid header region as part of the header structure. Consequently, the driver writes metadata or header updates into adjacent stack memory.\nThis vulnerability is triggered without any requirement for user-space authentication or elevated privileges, as it occurs within the kernel-mode driver processing logic. It is exposed to any network environment where the device is active and receiving traffic. The impact is significant because stack corruption often leads to immediate kernel panic (a system crash) or, under specific memory layout conditions, enables an attacker to overwrite critical function pointers or return addresses stored on the stack to redirect execution flow.\nThe issue is exacerbated by the reliance on hardware-provided length fields without secondary validation by the software layer. By ensuring that the SKB length does not exceed the maximum allowed header size before memory access, the driver can drop malicious packets rather than allowing the illegal memory modification to persist."
}