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

[Jeff Johnson <jeff.johnson@oss.qualcomm.com>]

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.

/jeff