On Fri, Apr 08, 2022 at 12:19:01AM -0700, Joe Perches wrote:
> On Fri, 2022-04-08 at 09:31 +0300, Dan Carpenter wrote:
> > On Thu, Apr 07, 2022 at 11:14:51PM -0700, Joe Perches wrote:
> > > On Fri, 2022-04-08 at 08:57 +0300, Dan Carpenter wrote:
> > > > On Fri, Apr 08, 2022 at 06:15:14AM +0200, Julia Lawall wrote:
> > > > > On Thu, 7 Apr 2022, Rebecca Mckeever wrote:
> > > > >
> > > > > > Replace ternary statement with an if statement followed by an assignment
> > > > > > to increase readability and make error handling more obvious.
> > > > > > Found with minmax coccinelle script.
> > > []
> > > > > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> > > []
> > > > > > @@ -470,7 +470,9 @@ int ieee80211_wx_get_encode(struct ieee80211_device *ieee,
> > > > > > return 0;
> > > > > > }
> > > > > > len = crypt->ops->get_key(keybuf, SCM_KEY_LEN, NULL, crypt->priv);
> > > > > > - erq->length = (len >= 0 ? len : 0);
> > > > > > + if (len < 0)
> > > > > > + len = 0;
> > > > > > + erq->length = len;
> > > > >
> > > > > Maybe you could use max here?
> > > >
> > > > Initially Rebecca did use max() but I NAKed it. It's really not less
> > > > readable. Better to handle the error explicitly. Keep the error path
> > > > indented two tabs. Separate from the success path.
> > >
> > > A comment would be useful as it's not obvious it's an 'error' path.
> > > One has to read all 3 get_key functions to determine that.
> > >
> >
> > I'm so confused. Negative error codes are the common case in the
> > kernel. We don't need to comment it.
>
> If it was an error, it would handle it as an error not set
> len to 0 and continue. That's why IMO a comment is useful.
Yeah. You're probably right. My understanding is that a zero length
key is a special case where it uses the default key? Which I guess is
all zeroes here.
if (len < 0) {
/* No key data. Use the default key. */
len = 0;
}
But when I look at this some more then there are three ->get_key()
callers in this file and only this one checks for -1 returns. For the
one caller that does this:
ext->key_len = crypt->ops->get_key(ext->key, SCM_KEY_LEN, NULL, crypt->priv);
then a negative return would result in a buffer overflow.
So another option would be to just return 0 instead of -1 from the
get_key() functions.
File | Pointer | Function | Static
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | (struct ieee80211_crypto_ops)->get_key | ieee80211_tkip_get_key | 1
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | (struct ieee80211_crypto_ops)->get_key | prism2_wep_get_key | 1
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | (struct ieee80211_crypto_ops)->get_key | ieee80211_ccmp_get_key | 1
Changing it to return zero would leave ieee80211_wx_get_encode() behavior
as-is. It would fix a buffer overflow in ieee80211_wx_get_encode_ext().
It is a behavior change in ieee80211_wx_set_encode() and I think that's
a bug fix as well.
regards,
dan carpenter
