Hi, Since I'm covering for Kalle right now ... On Sun, 2023-08-06 at 23:08 -0400, Wen Gong wrote: > If cfg80211 is providing extraie's for a scanning process then ath12k will > copy that over to the firmware. The extraie.len is a 32 bit value in struct > element_info and describes the amount of bytes for the vendor information > elements. > > The WMI_TLV packet is having a special WMI_TAG_ARRAY_BYTE section. This > section can have a (payload) length up to 65535 bytes because the > WMI_TLV_LEN can store up to 16 bits. The code was missing such a check and > could have created a scan request which cannot be parsed correctly by the > firmware. > > But the bigger problem was the allocation of the buffer. It has to align > the TLV sections by 4 bytes. But the code was using an u8 to store the > newly calculated length of this section (with alignment). And the new > calculated length was then used to allocate the skbuff. But the actual code > to copy in the data is using the extraie.len and not the calculated > "aligned" length. > > The length of extraie with IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS enabled > was 264 bytes during tests with a wifi card. But it only allocated 8 > bytes (264 bytes % 256) for it. As consequence, the code to memcpy the > extraie into the skb was then just overwriting data after skb->end. Things > like shinfo were therefore corrupted. This could usually be seen by a crash > in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogus > address). I feel these are two separate issues. Having a large enough TLV that the firmware cannot parse it is highly unlikely to happen, and not really an issue here. Please split this into two patches, and fix *just* the buffer overflow in a patch titled "Fix buffer overflow". I believe simply changing the variable type is sufficient for this, as the code is otherwise equivalent. That's a patch I'd take to wireless at this stage (rc5), but probably not the entire bigger change. johannes
