[PATCH 0/5] wifi: ath11k/ath12k: validate capability TLV lengths

[jiale yao]

At 2026-10-29 08:28:10, "Jeff Johnson" <jeff.johnson at oss.qualcomm.com> wrote:
>On 10/27/2026 10:12 PM, Jiale Yao wrote:
>> Several ath11k and ath12k WMI parsers count firmware TLVs and later
>> consume them as arrays of complete capability structures.  The generic
>> iterator validates that a TLV fits in its enclosing message, but these
>> tags have no minimum-length policies, so a short element can still cause
>> an out-of-bounds structure read.
>> 
>> Add policies for the DMA buffer release, hardware mode, DMA ring, and
>> extended MAC/PHY capability TLVs used by these paths.
>> 
>> Jiale Yao (5):
>>   wifi: ath11k: validate DMA buffer release TLV lengths
>>   wifi: ath11k: validate hardware mode capability TLVs
>>   wifi: ath11k: validate DMA ring capability TLVs
>>   wifi: ath12k: validate DMA buffer release fixed TLV length
>>   wifi: ath12k: validate service-ready capability TLV lengths
>> 
>>  drivers/net/wireless/ath/ath11k/wmi.c | 8 ++++++++
>>  drivers/net/wireless/ath/ath12k/wmi.c | 8 ++++++++
>>  2 files changed, 16 insertions(+)
>> 
>
>I was surprised by the asymmetry between patch 1 (which just added validation
>to the array entry TLVs) and patch 4 (which just added validation to the fixed
>params TLV). After a session with an LLM we came to the conclusion that both
>are incomplete:
>
>The DMA-buf-release event has two independent OOB sinks in each driver — a
>fixed-header copy and a fixed-stride array walk. Both drivers are affected by
>both. The series fixes only one sink per driver, and in a complementary
>pattern that makes each driver look "done" at a glance but leaves each one
>half-covered:
>
>- ath11k: patch 1 guards the array elements (_ENTRY, _META_DATA) ✅ but the
>fixed-header memcpy at wmi.c:4669 (16 bytes, unconditional, from firmware
>payload) is still unguarded. Needs the [WMI_TAG_DMA_BUF_RELEASE] policy.
>- ath12k: patch 4 guards the fixed header ✅ but the array stride reads
>ev->buf_entry[i] / ev->meta_data[i] in dbring.c are still unguarded. Needs the
>[WMI_TAG_DMA_BUF_RELEASE_ENTRY] and [..._SPECTRAL_META_DATA] policies.
>
>And since you are playing in this area, my LLM thinks that
>WMI_TAG_HAL_REG_CAPABILITIES_EXT has this issue in both drivers, and thinks
>that WMI_TAG_RSSI_STATS may have this issue. I haven't verified that analysis.

Agree, the updated one is here, https://lore.kernel.org/lkml/20261029041811.2379878-1-yaojiale02@163.com/
>
>/jeff