| Message ID | 20240702122450.2213833-1-suhui@nfschina.com |
|---|---|
| Headers | show |
| Series | wifi: cfg80211: avoid some garbage values | expand |
On Tue, 2024-07-02 at 20:24 +0800, Su Hui wrote: > > Su Hui (9): > wifi: cfg80211: avoid garbage value of 'io_type' in > brcmf_cfg80211_attach() > wifi: brcmfmac: avoid garbage value of 'status' in > brcmf_c_download_blob() > wifi: cfg80211: avoid garbage value of 'noise' in > brcmf_cfg80211_dump_survey() > wifi: cfg80211: avoid garbage value of 'chanspec' in > brcmf_cfg80211_get_channel() > wifi: cfg80211: avoid garbage value of 'freq' in > brcmf_cfg80211_mgmt_tx() > wifi: cfg80211: avoid garbage value of 'wsec' in > brcmf_cfg80211_reconfigure_wep() > wifi: cfg80211: avoid garbage value of 'wsec' in > brcmf_cfg80211_add_key() > wifi: cfg80211: avoid garbage value of 'val' in brcmf_set_key_mgmt() > wifi: cfg80211: avoid garbage value of 'wsec' in > brcmf_cfg80211_{get,config_default}_key() > Uh where did all those line breaks come from? anyway all the titles are wrong - all of this is brcmfmac, not cfg80211. johannes
Hi, On Tue, 2 Jul 2024 at 14:50, Su Hui <suhui@nfschina.com> wrote: > > Clang static checker (scan-build) has some warnings as follows. > > included from drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c:16 > drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h:123:2: > warning:Assigned value is garbage or undefined [core.uninitialized.Assign] > 123 | __le32 data_le = cpu_to_le32(*data); > | ^~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ > drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c:138:3:warning > Value stored to 'err' is never read [deadcode.DeadStores] > > There are some functions like brcmf_fil_{cmd,iovar,basscfg}_int_get() > which read the value of its parameter, but some callers have not > initialized these parameters which will be read. And this patchset fixes > these problems. The core issue here seems to be that brcmf_fil_{cmd,iovar,basscfg}_int_get() function (needlessly?) read from *data. So instead of forcing all callers of brcmf_fil_{cmd,iovar,basscfg}_int_get() to initialize *data first, I suggest changing brcmf_fil_{cmd,iovar,basscfg}_int_get() to just not read from it. I see no reason why they should care about what the previous value was, since they are supposed to overwrite it anyway. Best Regards, Jonas
On July 2, 2024 4:02:39 PM Jonas Gorski <jonas.gorski@gmail.com> wrote: > Hi, > > On Tue, 2 Jul 2024 at 14:50, Su Hui <suhui@nfschina.com> wrote: >> >> Clang static checker (scan-build) has some warnings as follows. >> >> included from drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c:16 >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h:123:2: >> warning:Assigned value is garbage or undefined [core.uninitialized.Assign] >> 123 | __le32 data_le = cpu_to_le32(*data); >> | ^~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c:138:3:warning >> Value stored to 'err' is never read [deadcode.DeadStores] >> >> There are some functions like brcmf_fil_{cmd,iovar,basscfg}_int_get() >> which read the value of its parameter, but some callers have not >> initialized these parameters which will be read. And this patchset fixes >> these problems. > > The core issue here seems to be that > brcmf_fil_{cmd,iovar,basscfg}_int_get() function (needlessly?) read > from *data. > > So instead of forcing all callers of > brcmf_fil_{cmd,iovar,basscfg}_int_get() to initialize *data first, I > suggest changing brcmf_fil_{cmd,iovar,basscfg}_int_get() to just not > read from it. > > I see no reason why they should care about what the previous value > was, since they are supposed to overwrite it anyway. The issue here is that these are generic functions and there is a reason. Some firmware API primitives allow/require the caller to pass selection parameters in *data. We wanted to keep the functions generic and leave out that knowledge. I suppose we could introduce a separate set of api functions for that purpose, but it seems like significant overhead to silence compiler warnings. Guess I underestimate the potential risk of leaking few bytes of stack data. Regards, Arend
Arend Van Spriel <arend.vanspriel@broadcom.com> writes: > On July 2, 2024 3:57:27 PM Dan Carpenter <dan.carpenter@linaro.org> wrote: > >> On Tue, Jul 02, 2024 at 08:24:44PM +0800, Su Hui wrote: >>> brcmf_fil_cmd_int_get() reads the value of 'io_type' and passes it to >>> brcmf_fil_cmd_data_get(). Initialize 'io_type' to avoid garbage value. >> >> Since you're going to be resending anyway, please delete the space char >> from the start of the line. >> >> It's weird that brcmf_fil_cmd_data_get() uses the uninitialized data. >> It looks like it just goes to great lengths to preserve the original >> data in io_type... So it likely is harmless enough but still a strange >> and complicated way write a no-op. > > Not sure if it helps, but I tried to explain the reason in response to > patch 0 (cover letter). Would it make more sense to have just one patch? It's the same issue anyway.
On July 2, 2024 5:29:27 PM Kalle Valo <kvalo@kernel.org> wrote: > Arend Van Spriel <arend.vanspriel@broadcom.com> writes: > >> On July 2, 2024 3:57:27 PM Dan Carpenter <dan.carpenter@linaro.org> wrote: >> >>> On Tue, Jul 02, 2024 at 08:24:44PM +0800, Su Hui wrote: >>>> brcmf_fil_cmd_int_get() reads the value of 'io_type' and passes it to >>>> brcmf_fil_cmd_data_get(). Initialize 'io_type' to avoid garbage value. >>> >>> Since you're going to be resending anyway, please delete the space char >>> from the start of the line. >>> >>> It's weird that brcmf_fil_cmd_data_get() uses the uninitialized data. >>> It looks like it just goes to great lengths to preserve the original >>> data in io_type... So it likely is harmless enough but still a strange >>> and complicated way write a no-op. >> >> Not sure if it helps, but I tried to explain the reason in response to >> patch 0 (cover letter). > > Would it make more sense to have just one patch? It's the same issue > anyway. Yes, but I would solve it in brcmf_fil_* functions (fwil.[ch]). Regards, Arend > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Clang static checker (scan-build) has some warnings as follows. included from drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c:16 drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h:123:2: warning:Assigned value is garbage or undefined [core.uninitialized.Assign] 123 | __le32 data_le = cpu_to_le32(*data); | ^~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c:138:3:warning Value stored to 'err' is never read [deadcode.DeadStores] There are some functions like brcmf_fil_{cmd,iovar,basscfg}_int_get() which read the value of its parameter, but some callers have not initialized these parameters which will be read. And this patchset fixes these problems. BTW, maybe merge this patchset into one patch is more better because the num of changed code is small. I split it into multiple patches because of these different 'Fixes' tags. Su Hui (9): wifi: cfg80211: avoid garbage value of 'io_type' in brcmf_cfg80211_attach() wifi: brcmfmac: avoid garbage value of 'status' in brcmf_c_download_blob() wifi: cfg80211: avoid garbage value of 'noise' in brcmf_cfg80211_dump_survey() wifi: cfg80211: avoid garbage value of 'chanspec' in brcmf_cfg80211_get_channel() wifi: cfg80211: avoid garbage value of 'freq' in brcmf_cfg80211_mgmt_tx() wifi: cfg80211: avoid garbage value of 'wsec' in brcmf_cfg80211_reconfigure_wep() wifi: cfg80211: avoid garbage value of 'wsec' in brcmf_cfg80211_add_key() wifi: cfg80211: avoid garbage value of 'val' in brcmf_set_key_mgmt() wifi: cfg80211: avoid garbage value of 'wsec' in brcmf_cfg80211_{get,config_default}_key() .../broadcom/brcm80211/brcmfmac/cfg80211.c | 18 +++++++++--------- .../broadcom/brcm80211/brcmfmac/common.c | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-)