* re: brcm80211: use endian annotation for pmk related structure
@ 2014-10-31 12:51 Dan Carpenter
2014-10-31 14:18 ` Arend van Spriel
0 siblings, 1 reply; 5+ messages in thread
From: Dan Carpenter @ 2014-10-31 12:51 UTC (permalink / raw)
To: arend; +Cc: linux-wireless, brcm80211-dev-list
Hello Arend van Spriel,
The patch 40c8e95af02d: "brcm80211: use endian annotation for pmk
related structure" from Oct 12, 2011, leads to the following static
checker warning:
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c:2965 brcmf_cfg80211_set_pmksa()
warn: can 'pmkid_len' be negative?
drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
2950 brcmf_cfg80211_set_pmksa(struct wiphy *wiphy, struct net_device *ndev,
2951 struct cfg80211_pmksa *pmksa)
2952 {
2953 struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
2954 struct brcmf_if *ifp = netdev_priv(ndev);
2955 struct pmkid_list *pmkids = &cfg->pmk_list->pmkids;
2956 s32 err = 0;
2957 int i;
2958 int pmkid_len;
2959
2960 brcmf_dbg(TRACE, "Enter\n");
2961 if (!check_vif_up(ifp->vif))
2962 return -EIO;
2963
2964 pmkid_len = le32_to_cpu(pmkids->npmkid);
The thinking behind this check is that endian data is less trust worthy
than cpu data. But probably this comes from the hardware so it's fine?
Anyway, let's assume pmkid_len = -1.
2965 for (i = 0; i < pmkid_len; i++)
2966 if (!memcmp(pmksa->bssid, pmkids->pmkid[i].BSSID, ETH_ALEN))
2967 break;
We don't enter this loop.
2968 if (i < WL_NUM_PMKIDS_MAX) {
Zero is less than WL_NUM_PMKIDS_MAX.
2969 memcpy(pmkids->pmkid[i].BSSID, pmksa->bssid, ETH_ALEN);
2970 memcpy(pmkids->pmkid[i].PMKID, pmksa->pmkid, WLAN_PMKID_LEN);
2971 if (i == pmkid_len) {
^^^^^^^^^^^^^^
This is false.
2972 pmkid_len++;
2973 pmkids->npmkid = cpu_to_le32(pmkid_len);
2974 }
2975 } else
2976 err = -EINVAL;
2977
2978 brcmf_dbg(CONN, "set_pmksa,IW_PMKSA_ADD - PMKID: %pM =\n",
2979 pmkids->pmkid[pmkid_len].BSSID);
^^^^^^^^^^^^^^^^^^^^^^^
Underflow.
2980 for (i = 0; i < WLAN_PMKID_LEN; i++)
2981 brcmf_dbg(CONN, "%02x\n", pmkids->pmkid[pmkid_len].PMKID[i]);
^^^^^^^^^^^^^^^^^^^^^^^^
Underflow.
2982
2983 err = brcmf_update_pmklist(ndev, cfg->pmk_list, err);
2984
2985 brcmf_dbg(TRACE, "Exit\n");
2986 return err;
2987 }
regards,
dan carpenter
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: brcm80211: use endian annotation for pmk related structure
2014-10-31 12:51 brcm80211: use endian annotation for pmk related structure Dan Carpenter
@ 2014-10-31 14:18 ` Arend van Spriel
2014-10-31 14:26 ` Dan Carpenter
0 siblings, 1 reply; 5+ messages in thread
From: Arend van Spriel @ 2014-10-31 14:18 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless, brcm80211-dev-list
On 10/31/14 13:51, Dan Carpenter wrote:
> Hello Arend van Spriel,
>
> The patch 40c8e95af02d: "brcm80211: use endian annotation for pmk
> related structure" from Oct 12, 2011, leads to the following static
> checker warning:
>
> drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c:2965 brcmf_cfg80211_set_pmksa()
> warn: can 'pmkid_len' be negative?
>
> drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
> 2950 brcmf_cfg80211_set_pmksa(struct wiphy *wiphy, struct net_device *ndev,
> 2951 struct cfg80211_pmksa *pmksa)
> 2952 {
> 2953 struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
> 2954 struct brcmf_if *ifp = netdev_priv(ndev);
> 2955 struct pmkid_list *pmkids =&cfg->pmk_list->pmkids;
> 2956 s32 err = 0;
> 2957 int i;
> 2958 int pmkid_len;
> 2959
> 2960 brcmf_dbg(TRACE, "Enter\n");
> 2961 if (!check_vif_up(ifp->vif))
> 2962 return -EIO;
> 2963
> 2964 pmkid_len = le32_to_cpu(pmkids->npmkid);
>
> The thinking behind this check is that endian data is less trust worthy
> than cpu data. But probably this comes from the hardware so it's fine?
>
> Anyway, let's assume pmkid_len = -1.
>
> 2965 for (i = 0; i< pmkid_len; i++)
> 2966 if (!memcmp(pmksa->bssid, pmkids->pmkid[i].BSSID, ETH_ALEN))
> 2967 break;
>
> We don't enter this loop.
>
> 2968 if (i< WL_NUM_PMKIDS_MAX) {
>
> Zero is less than WL_NUM_PMKIDS_MAX.
>
> 2969 memcpy(pmkids->pmkid[i].BSSID, pmksa->bssid, ETH_ALEN);
> 2970 memcpy(pmkids->pmkid[i].PMKID, pmksa->pmkid, WLAN_PMKID_LEN);
> 2971 if (i == pmkid_len) {
> ^^^^^^^^^^^^^^
> This is false.
>
> 2972 pmkid_len++;
> 2973 pmkids->npmkid = cpu_to_le32(pmkid_len);
> 2974 }
> 2975 } else
> 2976 err = -EINVAL;
> 2977
> 2978 brcmf_dbg(CONN, "set_pmksa,IW_PMKSA_ADD - PMKID: %pM =\n",
> 2979 pmkids->pmkid[pmkid_len].BSSID);
> ^^^^^^^^^^^^^^^^^^^^^^^
> Underflow.
>
> 2980 for (i = 0; i< WLAN_PMKID_LEN; i++)
> 2981 brcmf_dbg(CONN, "%02x\n", pmkids->pmkid[pmkid_len].PMKID[i]);
> ^^^^^^^^^^^^^^^^^^^^^^^^
> Underflow.
>
> 2982
> 2983 err = brcmf_update_pmklist(ndev, cfg->pmk_list, err);
> 2984
> 2985 brcmf_dbg(TRACE, "Exit\n");
> 2986 return err;
> 2987 }
Hi Dan,
Understood. Not sure what the motivation is to mistrust endian more.
Simply because there could be conversion errors? Anyway, the main
question is whether pmkid_len is always between 0 and WLAN_PMKID_LEN. As
far as I know it is. We could 1) add additional checks here, 2) make
pmkid_len of u32 type, or 3) just mention the (sure) assumption in a
comment. I would prefer option 2) or 3).
Regards,
Arend
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: brcm80211: use endian annotation for pmk related structure
2014-10-31 14:18 ` Arend van Spriel
@ 2014-10-31 14:26 ` Dan Carpenter
2014-10-31 14:37 ` Arend van Spriel
0 siblings, 1 reply; 5+ messages in thread
From: Dan Carpenter @ 2014-10-31 14:26 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, brcm80211-dev-list
On Fri, Oct 31, 2014 at 03:18:27PM +0100, Arend van Spriel wrote:
> Understood. Not sure what the motivation is to mistrust endian more.
Endian data tends to come from suspicious places such as disk images,
usb devices, and networks.
> Simply because there could be conversion errors? Anyway, the main
> question is whether pmkid_len is always between 0 and
> WLAN_PMKID_LEN. As far as I know it is. We could 1) add additional
> checks here, 2) make pmkid_len of u32 type, or 3) just mention the
> (sure) assumption in a comment. I would prefer option 2) or 3).
I would prefer 2. Static checker warnings are a pain.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: brcm80211: use endian annotation for pmk related structure
2014-10-31 14:26 ` Dan Carpenter
@ 2014-10-31 14:37 ` Arend van Spriel
2014-11-03 12:22 ` Dan Carpenter
0 siblings, 1 reply; 5+ messages in thread
From: Arend van Spriel @ 2014-10-31 14:37 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-wireless, brcm80211-dev-list
On 10/31/14 15:26, Dan Carpenter wrote:
> On Fri, Oct 31, 2014 at 03:18:27PM +0100, Arend van Spriel wrote:
>> Understood. Not sure what the motivation is to mistrust endian more.
>
> Endian data tends to come from suspicious places such as disk images,
> usb devices, and networks.
>
>> Simply because there could be conversion errors? Anyway, the main
>> question is whether pmkid_len is always between 0 and
>> WLAN_PMKID_LEN. As far as I know it is. We could 1) add additional
>> checks here, 2) make pmkid_len of u32 type, or 3) just mention the
>> (sure) assumption in a comment. I would prefer option 2) or 3).
>
> I would prefer 2. Static checker warnings are a pain.
Now who has been tinkering on static checkers ;-) Anyway, option 2) it
is. Who will do the patch? :-p
Regards,
Arend
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: brcm80211: use endian annotation for pmk related structure
2014-10-31 14:37 ` Arend van Spriel
@ 2014-11-03 12:22 ` Dan Carpenter
0 siblings, 0 replies; 5+ messages in thread
From: Dan Carpenter @ 2014-11-03 12:22 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, brcm80211-dev-list
On Fri, Oct 31, 2014 at 03:37:36PM +0100, Arend van Spriel wrote:
> On 10/31/14 15:26, Dan Carpenter wrote:
> >On Fri, Oct 31, 2014 at 03:18:27PM +0100, Arend van Spriel wrote:
> >>Understood. Not sure what the motivation is to mistrust endian more.
> >
> >Endian data tends to come from suspicious places such as disk images,
> >usb devices, and networks.
> >
> >>Simply because there could be conversion errors? Anyway, the main
> >>question is whether pmkid_len is always between 0 and
> >>WLAN_PMKID_LEN. As far as I know it is. We could 1) add additional
> >>checks here, 2) make pmkid_len of u32 type, or 3) just mention the
> >>(sure) assumption in a comment. I would prefer option 2) or 3).
> >
> >I would prefer 2. Static checker warnings are a pain.
>
> Now who has been tinkering on static checkers ;-) Anyway, option 2)
> it is. Who will do the patch? :-p
Actually, in the end making it unsigned doesn't make sense because we
don't check for upper bound either.
Let's just forget about it.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-11-03 12:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-31 12:51 brcm80211: use endian annotation for pmk related structure Dan Carpenter
2014-10-31 14:18 ` Arend van Spriel
2014-10-31 14:26 ` Dan Carpenter
2014-10-31 14:37 ` Arend van Spriel
2014-11-03 12:22 ` Dan Carpenter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).