CVE-2026-97442: wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix invalid data access in ath11kdprxhundecapnwifi
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 ath11kdprxhundecapnwifi() function for the DPRXDECAPTYPENATIVEWIFI decap type and potentially result in invalid data access and memory corruption.
Kernel stack is corrupted in: ath11kdprxhundecap+0x6b0/0x6b0 [ath11k] Call trace: ath11kdprxhmpdu+0x0/0x2e8 [ath11k] ath11kdprxhmpdu+0x1e0/0x2e8 [ath11k] ath11kdprxwbmerr+0x1e0/0x450 [ath11k] ath11kdprxprocesswbmerr+0x2fc/0x460 [ath11k] ath11kdpservicesrng+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 DPRXDECAPTYPENATIVEWIFI decap type.
This adapted from the discussion/patch of the ath12k driver [1].
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPLV1V2SILICONZIOE-1
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Add a sanity check in ath11k_dp_rx_h_undecap_nwifi() before processing the SKB to reject invalid DP_RX_DECAP_TYPE_NATIVE_WIFI decap types and packets whose data length exceeds the maximum native Wi-Fi header length.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel ath11k Wi-Fi driver are implicated, specifically when processing receive traffic with the DP_RX_DECAP_TYPE_NATIVE_WIFI decapsulation type. The issue was tested on WCN6855 hardware, but the provided information does not limit impact to that hardware.
What conditions trigger the invalid access?
The hardware must provide a packet whose length exceeds the maximum native Wi-Fi header length. The ath11k receive path can then access and modify header fields in ath11k_dp_rx_h_undecap_nwifi(), potentially corrupting kernel memory.
How can I tell whether a system may already have encountered the issue?
A relevant failure may show kernel stack corruption involving ath11k_dp_rx_h_undecap or ath11k_dp_rx_h_undecap_nwifi, with call paths through ath11k_dp_rx_h_mpdu, ath11k_dp_rx_wbm_err, ath11k_dp_rx_process_wbm_err, and ath11k_dp_service_srng.
What mitigation is available if an updated kernel cannot be deployed immediately?
The provided fix adds a sanity check before processing the SKB for native Wi-Fi decapsulation. No temporary configuration workaround is specified in the available information.