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;
Date:   Mon, 31 Jul 2023 16:06:12 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     Arend van Spriel <aspriel@gmail.com>,
        Franky Lin <franky.lin@broadcom.com>,
        Hante Meuleman <hante.meuleman@broadcom.com>,
        Kalle Valo <kvalo@kernel.org>, linux-wireless@vger.kernel.org,
        brcm80211-dev-list.pdl@broadcom.com,
        SHA-cyfmac-dev-list@infineon.com
Subject: Re: [PATCH] wifi: brcmfmac: Fix field-spanning write in
 brcmf_scan_params_v2_to_v1()
Message-ID: <202307311605.706EEC44FD@keescook>
References: <20230729140500.27892-1-hdegoede@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230729140500.27892-1-hdegoede@redhat.com>
Precedence: bulk

On Sat, Jul 29, 2023 at 04:05:00PM +0200, Hans de Goede wrote:
> Using brcmfmac with 6.5-rc3 on a brcmfmac43241b4-sdio triggers
> a backtrace caused by the following field-spanning error:
> 
> memcpy: detected field-spanning write (size 120) of single field
>   "&params_le->channel_list[0]" at
>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1072 (size 2)
> 
> Fix this by replacing the channel_list[1] declaration at the end of
> the struct with a flexible array declaration.
> 
> Most users of struct brcmf_scan_params_le calculate the size to alloc
> using the size of the non flex-array part of the struct + needed extra
> space, so they do not care about sizeof(struct brcmf_scan_params_le).
> 
> brcmf_notify_escan_complete() however uses the struct on the stack,
> expecting there to be room for at least 1 entry in the channel-list
> to store the special -1 abort channel-id.
> 
> To make this work use an anonymous union with a padding member
> added + the actual channel_list flexible array.
> 
> Cc: Kees Cook <keescook@chromium.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Looks good to me; it's consistent with how similar 1-element arrays
with sensitive structure sizes have been updated lately. Thanks for
the investigation!

Reviewed-by: Kees Cook <keescook@chromium.org>

-Kees

-- 
Kees Cook