linux-stable v4.9.337 brcmfmac compilation error

linux-stable v4.9.337 brcmfmac compilation error

[Philippe De Muyter]

Hello,

compilation of the brcmfmac driver in linux-4.9.y (tag v4.9.337) fails with

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function ‘brcmf_fw_map_chip_to_name’:
 include/linux/stddef.h:7:14: error: return makes integer from pointer without a cast [-Werror=int-conversion]
  #define NULL ((void *)0)
               ^
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:577:10: note: in expansion of macro ‘NULL’
    return NULL;
           ^~~~
 cc1: all warnings being treated as errors

This is caused by commit 1db036d13e10809943c2dce553e2fa7fc9c6cd80
 wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()

    [ Upstream commit 81d17f6f3331f03c8eafdacea68ab773426c1e3c ]

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 33a7378..6675de1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -572,6 +572,11 @@ int brcmf_fw_map_chip_to_name(u32 chip, u32 chiprev,
        u32 i;
        char end;

+       if (chiprev >= BITS_PER_TYPE(u32)) {
+               brcmf_err("Invalid chip revision %u\n", chiprev);
+               return NULL;
+       }
+
        for (i = 0; i < table_size; i++) {
                if (mapping_table[i].chipid == chip &&
                    mapping_table[i].revmask & BIT(chiprev))

The problem is that in the upstream commit, the patch is applied to
brcmf_fw_alloc_request(), which returns a pointer, while in v4.9.337
it is applied to brcmf_fw_map_chip_to_name() which returns 'int'.

Should we simply revert that patch, or rather add the missing
intermediate patches ?

Best regards

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles

Re: linux-stable v4.9.337 brcmfmac compilation error

[Greg KH]

On Wed, Jul 19, 2023 at 08:48:12AM +0200, Philippe De Muyter wrote:
> Hello,
> 
> compilation of the brcmfmac driver in linux-4.9.y (tag v4.9.337) fails with
> 
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function ‘brcmf_fw_map_chip_to_name’:
>  include/linux/stddef.h:7:14: error: return makes integer from pointer without a cast [-Werror=int-conversion]
>   #define NULL ((void *)0)
>                ^
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:577:10: note: in expansion of macro ‘NULL’
>     return NULL;
>            ^~~~
>  cc1: all warnings being treated as errors
> 
> This is caused by commit 1db036d13e10809943c2dce553e2fa7fc9c6cd80
>  wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()
> 
>     [ Upstream commit 81d17f6f3331f03c8eafdacea68ab773426c1e3c ]
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index 33a7378..6675de1 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -572,6 +572,11 @@ int brcmf_fw_map_chip_to_name(u32 chip, u32 chiprev,
>         u32 i;
>         char end;
> 
> +       if (chiprev >= BITS_PER_TYPE(u32)) {
> +               brcmf_err("Invalid chip revision %u\n", chiprev);
> +               return NULL;
> +       }
> +
>         for (i = 0; i < table_size; i++) {
>                 if (mapping_table[i].chipid == chip &&
>                     mapping_table[i].revmask & BIT(chiprev))
> 
> The problem is that in the upstream commit, the patch is applied to
> brcmf_fw_alloc_request(), which returns a pointer, while in v4.9.337
> it is applied to brcmf_fw_map_chip_to_name() which returns 'int'.
> 
> Should we simply revert that patch, or rather add the missing
> intermediate patches ?

4.9.y is long end-of-life and not accepting any more patches.  Please
work with your kernel vendor to not be using it anymore as it is
obsolete and known to have unfixed security issues.

sorry,

greg k-h