Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6ccf4549011f0efa67523d1c171b23694122ec6c.camel@sipsolutions.net>
Subject: Re: [PATCH] wifi: ath12k: Fix buffer overflow when scanning with
 extraie
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Wen Gong <quic_wgong@quicinc.com>, ath12k@lists.infradead.org
Cc:     linux-wireless@vger.kernel.org
Date:   Tue, 08 Aug 2023 12:55:42 +0200
In-Reply-To: <20230807030806.9345-1-quic_wgong@quicinc.com>
References: <20230807030806.9345-1-quic_wgong@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

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 wil=
l
> copy that over to the firmware. The extraie.len is a 32 bit value in stru=
ct
> element_info and describes the amount of bytes for the vendor information
> elements.
>=20
> 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 an=
d
> could have created a scan request which cannot be parsed correctly by the
> firmware.
>=20
> 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 co=
de
> to copy in the data is using the extraie.len and not the calculated
> "aligned" length.
>=20
> 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. Thing=
s
> like shinfo were therefore corrupted. This could usually be seen by a cra=
sh
> in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogu=
s
> 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