| Message ID | 20220118154514.3245524-1-phil@raspberrypi.com |
|---|---|
| State | New |
| Headers | show |
| Series | brcmfmac: firmware: Fix crash in brcm_alt_fw_path | expand |
Phil Elwell <phil@raspberrypi.com> writes: > The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected > by a check to the validity of the fwctx->req->board_type pointer. This > results in a crash in strlcat when, for example, the WLAN chip is found > in a USB dongle. > > Prevent the crash by adding the necessary check. > > See: https://github.com/raspberrypi/linux/issues/4833 > > Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") > Signed-off-by: Phil Elwell <phil@raspberrypi.com> I think this should go to v5.17.
On 19/01/2022 06:01, Kalle Valo wrote: > Phil Elwell <phil@raspberrypi.com> writes: > >> The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected >> by a check to the validity of the fwctx->req->board_type pointer. This >> results in a crash in strlcat when, for example, the WLAN chip is found >> in a USB dongle. >> >> Prevent the crash by adding the necessary check. >> >> See: https://github.com/raspberrypi/linux/issues/4833 >> >> Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") >> Signed-off-by: Phil Elwell <phil@raspberrypi.com> > > I think this should go to v5.17. Is that an Ack? Are you asking me to submit the patch in a different way? Phil
Phil Elwell <phil@raspberrypi.com> writes: > On 19/01/2022 06:01, Kalle Valo wrote: >> Phil Elwell <phil@raspberrypi.com> writes: >> >>> The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected >>> by a check to the validity of the fwctx->req->board_type pointer. This >>> results in a crash in strlcat when, for example, the WLAN chip is found >>> in a USB dongle. >>> >>> Prevent the crash by adding the necessary check. >>> >>> See: https://github.com/raspberrypi/linux/issues/4833 >>> >>> Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") >>> Signed-off-by: Phil Elwell <phil@raspberrypi.com> >> >> I think this should go to v5.17. > > Is that an Ack? It's a note to myself and other maintainers/reviewers that I'm planning to take this to the wireless tree. At the moment I'm waiting for other people to comment. > Are you asking me to submit the patch in a different way? No need, unless something is found during review.
Arend van Spriel <arend.vanspriel@broadcom.com> writes: > On 1/27/2022 1:08 PM, Kalle Valo wrote: >> Arend van Spriel <arend.vanspriel@broadcom.com> writes: >> >>> On 1/19/2022 9:53 AM, Phil Elwell wrote: >>>> On 19/01/2022 06:01, Kalle Valo wrote: >>>>> Phil Elwell <phil@raspberrypi.com> writes: >>>>> >>>>>> The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected >>>>>> by a check to the validity of the fwctx->req->board_type pointer. This >>>>>> results in a crash in strlcat when, for example, the WLAN chip is found >>>>>> in a USB dongle. >>>>>> >>>>>> Prevent the crash by adding the necessary check. >>>>>> >>>>>> See: https://github.com/raspberrypi/linux/issues/4833 >>>>>> >>>>>> Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware >>>>>> binaries") >>>>>> Signed-off-by: Phil Elwell <phil@raspberrypi.com> >>>>> >>>>> I think this should go to v5.17. >>>> >>>> Is that an Ack? Are you asking me to submit the patch in a different way? >>> >>> Similar/same patch was submitted by Hector Martin [1]. > > Fine by me. Hector's subset series (fixes) is ready to be taken as > well, right? I have not looked at Hector's patches yet, my plan is to take them to wireless-next.
On 1/27/2022 2:17 PM, Kalle Valo wrote: > Arend van Spriel <arend.vanspriel@broadcom.com> writes: > >> On 1/27/2022 1:08 PM, Kalle Valo wrote: >>> Arend van Spriel <arend.vanspriel@broadcom.com> writes: >>> >>>> On 1/19/2022 9:53 AM, Phil Elwell wrote: >>>>> On 19/01/2022 06:01, Kalle Valo wrote: >>>>>> Phil Elwell <phil@raspberrypi.com> writes: >>>>>> >>>>>>> The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected >>>>>>> by a check to the validity of the fwctx->req->board_type pointer. This >>>>>>> results in a crash in strlcat when, for example, the WLAN chip is found >>>>>>> in a USB dongle. >>>>>>> >>>>>>> Prevent the crash by adding the necessary check. >>>>>>> >>>>>>> See: https://github.com/raspberrypi/linux/issues/4833 >>>>>>> >>>>>>> Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware >>>>>>> binaries") >>>>>>> Signed-off-by: Phil Elwell <phil@raspberrypi.com> >>>>>> >>>>>> I think this should go to v5.17. >>>>> >>>>> Is that an Ack? Are you asking me to submit the patch in a different way? >>>> >>>> Similar/same patch was submitted by Hector Martin [1]. >> >> Fine by me. Hector's subset series (fixes) is ready to be taken as >> well, right? > > I have not looked at Hector's patches yet, my plan is to take them to > wireless-next. Some of them are improvements so wireless-next is where those belong, but a few (patches #1-3, and #6) are actual bug fixes. Regards, Arend
Arend van Spriel <arend.vanspriel@broadcom.com> writes: > On 1/27/2022 2:17 PM, Kalle Valo wrote: >> Arend van Spriel <arend.vanspriel@broadcom.com> writes: >> >>> On 1/27/2022 1:08 PM, Kalle Valo wrote: >>>> Arend van Spriel <arend.vanspriel@broadcom.com> writes: >>>> >>>>> On 1/19/2022 9:53 AM, Phil Elwell wrote: >>>>>> On 19/01/2022 06:01, Kalle Valo wrote: >>>>>>> Phil Elwell <phil@raspberrypi.com> writes: >>>>>>> >>>>>>>> The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected >>>>>>>> by a check to the validity of the fwctx->req->board_type pointer. This >>>>>>>> results in a crash in strlcat when, for example, the WLAN chip is found >>>>>>>> in a USB dongle. >>>>>>>> >>>>>>>> Prevent the crash by adding the necessary check. >>>>>>>> >>>>>>>> See: https://github.com/raspberrypi/linux/issues/4833 >>>>>>>> >>>>>>>> Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware >>>>>>>> binaries") >>>>>>>> Signed-off-by: Phil Elwell <phil@raspberrypi.com> >>>>>>> >>>>>>> I think this should go to v5.17. >>>>>> >>>>>> Is that an Ack? Are you asking me to submit the patch in a different way? >>>>> >>>>> Similar/same patch was submitted by Hector Martin [1]. >>> >>> Fine by me. Hector's subset series (fixes) is ready to be taken as >>> well, right? >> >> I have not looked at Hector's patches yet, my plan is to take them to >> wireless-next. > > Some of them are improvements so wireless-next is where those belong, > but a few (patches #1-3, and #6) are actual bug fixes. To avoid conflicts I'm keeping the bar high for patches going to wireless, so it's mostly regression fixes or otherwise important fixes.
On 1/27/2022 4:36 PM, Kalle Valo wrote: > Arend van Spriel <arend.vanspriel@broadcom.com> writes: > >> On 1/27/2022 2:17 PM, Kalle Valo wrote: >>> Arend van Spriel <arend.vanspriel@broadcom.com> writes: >>> >>>> On 1/27/2022 1:08 PM, Kalle Valo wrote: >>>>> Arend van Spriel <arend.vanspriel@broadcom.com> writes: >>>>> >>>>>> On 1/19/2022 9:53 AM, Phil Elwell wrote: >>>>>>> On 19/01/2022 06:01, Kalle Valo wrote: >>>>>>>> Phil Elwell <phil@raspberrypi.com> writes: >>>>>>>> >>>>>>>>> The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected >>>>>>>>> by a check to the validity of the fwctx->req->board_type pointer. This >>>>>>>>> results in a crash in strlcat when, for example, the WLAN chip is found >>>>>>>>> in a USB dongle. >>>>>>>>> >>>>>>>>> Prevent the crash by adding the necessary check. >>>>>>>>> >>>>>>>>> See: https://github.com/raspberrypi/linux/issues/4833 >>>>>>>>> >>>>>>>>> Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware >>>>>>>>> binaries") >>>>>>>>> Signed-off-by: Phil Elwell <phil@raspberrypi.com> >>>>>>>> >>>>>>>> I think this should go to v5.17. >>>>>>> >>>>>>> Is that an Ack? Are you asking me to submit the patch in a different way? >>>>>> >>>>>> Similar/same patch was submitted by Hector Martin [1]. >>>> >>>> Fine by me. Hector's subset series (fixes) is ready to be taken as >>>> well, right? >>> >>> I have not looked at Hector's patches yet, my plan is to take them to >>> wireless-next. >> >> Some of them are improvements so wireless-next is where those belong, >> but a few (patches #1-3, and #6) are actual bug fixes. > > To avoid conflicts I'm keeping the bar high for patches going to > wireless, so it's mostly regression fixes or otherwise important fixes. Understood. No problem. Regards, Arend
Phil Elwell <phil@raspberrypi.com> wrote: > The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected > by a check to the validity of the fwctx->req->board_type pointer. This > results in a crash in strlcat when, for example, the WLAN chip is found > in a USB dongle. > > Prevent the crash by adding the necessary check. > > See: https://github.com/raspberrypi/linux/issues/4833 > > Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") > Signed-off-by: Phil Elwell <phil@raspberrypi.com> Patch applied to wireless.git, thanks. 665408f4c3a5 brcmfmac: firmware: Fix crash in brcm_alt_fw_path
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c index 0eb13e5df5177..d99140960a820 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c @@ -693,7 +693,7 @@ int brcmf_fw_get_firmwares(struct device *dev, struct brcmf_fw_request *req, { struct brcmf_fw_item *first = &req->items[0]; struct brcmf_fw *fwctx; - char *alt_path; + char *alt_path = NULL; int ret; brcmf_dbg(TRACE, "enter: dev=%s\n", dev_name(dev)); @@ -712,7 +712,9 @@ int brcmf_fw_get_firmwares(struct device *dev, struct brcmf_fw_request *req, fwctx->done = fw_cb; /* First try alternative board-specific path if any */ - alt_path = brcm_alt_fw_path(first->path, fwctx->req->board_type); + if (fwctx->req->board_type) + alt_path = brcm_alt_fw_path(first->path, + fwctx->req->board_type); if (alt_path) { ret = request_firmware_nowait(THIS_MODULE, true, alt_path, fwctx->dev, GFP_KERNEL, fwctx,
The call to brcm_alt_fw_path in brcmf_fw_get_firmwares is not protected by a check to the validity of the fwctx->req->board_type pointer. This results in a crash in strlcat when, for example, the WLAN chip is found in a USB dongle. Prevent the crash by adding the necessary check. See: https://github.com/raspberrypi/linux/issues/4833 Fixes: 5ff013914c62 ("brcmfmac: firmware: Allow per-board firmware binaries") Signed-off-by: Phil Elwell <phil@raspberrypi.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)