All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	outreachy@lists.linux.dev, Rebecca Mckeever <remckee0@gmail.com>
Subject: Re: [PATCH] staging: rtl8192u: change get_key functions to return 0 instead of -1
Date: Wed, 20 Apr 2022 16:52:36 +0200	[thread overview]
Message-ID: <3183776.G96rZvMJ2N@leap> (raw)
In-Reply-To: <Yl/7QPKXer7YtXOs@bertie>

On mercoledì 20 aprile 2022 14:23:28 CEST Rebecca Mckeever wrote:
> Currently, these three get_key functions return -1 when the provided len
> value is less a specific key length value, which can result in buffer
> overflow depending on how the returned value is used. These functions are
> used in three places in ieee80211/ieee80211_wx.c:
> 
>   ieee80211_wx_get_encode() :
>     The behavior of this function will be unchanged.
> 
>   ieee80211_wx_get_encode_ext() :
>     The result of the get_key function is written to ext->key_len,
>     resulting in a buffer overflow if the result is negative.
> 
>   ieee80211_wx_set_encode() :
>     The behavior of this function will change. When len is less than the
>     key length value, it will set a default key of all 0.
> 
> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Rebecca Mckeever <remckee0@gmail.com>
> ---
>  drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 2 +-
>  drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 2 +-
>  drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

I was not able to find the message where Dan suggested this solution. 
However it looks that we actually have problems in those callers when they 
get '-1' as the return code.

I didn't look at the code with much attention but I think that returning 
'0' to signal errors is not so good.

If I'm not missing something from the context, I'd rather return '-EINVAL' 
and change the callers to check for this specific error that would signal 
we have "len less than a specific len value". If so, act in accordance to 
the returned -EINVAL.

For example, in a caller you may test:

if (ext->key_len == -EINVAL || <some other test, if required>)
        <error path>
<success path>

Just my thoughts, but, as I said, I haven't checked carefully neither the 
callers nor the called functions. Maybe that returning '0' is the better 
solution, but it usually means that we have no errors. 

However, I'm 100% sure that, if Dan suggested this specific solution, there 
must be good reasons behind. If so, your changes are good :)

Thanks,

Fabio M. De Francesco

> 
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c b/
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
> index 101c28265e91..f17d07dad56d 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c
> @@ -362,7 +362,7 @@ static int ieee80211_ccmp_get_key(void *key, int len, 
u8 *seq, void *priv)
>  	struct ieee80211_ccmp_data *data = priv;
>  
>  	if (len < CCMP_TK_LEN)
> -		return -1;
> +		return 0;
>  
>  	if (!data->key_set)
>  		return 0;
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c b/
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
> index 689d8843f538..7b120b8cb982 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
> @@ -637,7 +637,7 @@ static int ieee80211_tkip_get_key(void *key, int len, 
u8 *seq, void *priv)
>  	struct ieee80211_tkip_data *tkey = priv;
>  
>  	if (len < TKIP_KEY_LEN)
> -		return -1;
> +		return 0;
>  
>  	if (!tkey->key_set)
>  		return 0;
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c b/
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> index 8a51ea1dd6e5..a2cdf3bfd1a4 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> @@ -201,7 +201,7 @@ static int prism2_wep_get_key(void *key, int len, u8 
*seq, void *priv)
>  	struct prism2_wep_data *wep = priv;
>  
>  	if (len < wep->key_len)
> -		return -1;
> +		return 0;
>  
>  	memcpy(key, wep->key, wep->key_len);
>  
> -- 
> 2.32.0
> 
> 
> 





  reply	other threads:[~2022-04-20 14:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 12:23 [PATCH] staging: rtl8192u: change get_key functions to return 0 instead of -1 Rebecca Mckeever
2022-04-20 14:52 ` Fabio M. De Francesco [this message]
2022-04-20 18:09   ` Dan Carpenter
2022-04-20 17:52 ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3183776.G96rZvMJ2N@leap \
    --to=fmdefrancesco@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=outreachy@lists.linux.dev \
    --cc=remckee0@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.