netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Hyunwoo Kim <v4bel@theori.io>,
	steffen.klassert@secunet.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	imv4bel@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH] xfrm: Zero padding when dumping algos and encap
Date: Wed, 8 Feb 2023 14:15:47 +0100	[thread overview]
Message-ID: <Y+Oggx0YBA3kLLcw@hog> (raw)
In-Reply-To: <Y+N4Q2B01iRfXlQu@gondor.apana.org.au>

2023-02-08, 18:24:03 +0800, Herbert Xu wrote:
> On Wed, Feb 08, 2023 at 12:54:34AM -0800, Hyunwoo Kim wrote:
> > On Tue, Feb 07, 2023 at 02:04:43PM +0800, Herbert Xu wrote:
> > > On Sat, Feb 04, 2023 at 09:50:18AM -0800, Hyunwoo Kim wrote:
> > > > Since x->calg etc. are allocated with kmalloc, information
> > > > in kernel heap can be leaked using netlink socket on
> > > > systems without CONFIG_INIT_ON_ALLOC_DEFAULT_ON.
> > > > 
> > Reported-by: syzbot+fa5414772d5c445dac3c@syzkaller.appspotmail.com
> 
> Thanks.  This line should go into the patch description.
> 
> However, I don't think your patch is sufficient as xfrm_user
> does the same thing as af_key.
> 
> I think a better approach would be to not copy out past the
> end of string in copy_to_user_state_extra.  Something like
> this:

Do you mean as a replacement for Hyunwoo's patch, or that both are
needed? pfkey_msg2xfrm_state doesn't always initialize encap_sport and
encap_dport (and calg->alg_key_len, but you're not using that in
copy_to_user_calg), so I guess you mean both patches.

> ---8<---
> When copying data to user-space we should ensure that only valid
> data is copied over.  Padding in structures may be filled with
> random (possibly sensitve) data and should never be given directly
> to user-space.
> 
> This patch fixes the copying of xfrm algorithms and the encap
> template in xfrm_user so that padding is zeroed.
> 
> Reported-by: syzbot+fa5414772d5c445dac3c@syzkaller.appspotmail.com
> Reported-by: Hyunwoo Kim <v4bel@theori.io>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index cf5172d4ce68..b5d50ae89840 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -1012,7 +1012,9 @@ static int copy_to_user_aead(struct xfrm_algo_aead *aead, struct sk_buff *skb)
>  		return -EMSGSIZE;
>  
>  	ap = nla_data(nla);
> -	memcpy(ap, aead, sizeof(*aead));
> +	strscpy_pad(ap->alg_name, aead->alg_name, sizeof(ap->alg_name));
> +	ap->alg_key_len = aead->alg_key_len;
> +	ap->alg_icv_len = aead->alg_icv_len;
>  
>  	if (redact_secret && aead->alg_key_len)
>  		memset(ap->alg_key, 0, (aead->alg_key_len + 7) / 8);
> @@ -1032,7 +1034,8 @@ static int copy_to_user_ealg(struct xfrm_algo *ealg, struct sk_buff *skb)
>  		return -EMSGSIZE;
>  
>  	ap = nla_data(nla);
> -	memcpy(ap, ealg, sizeof(*ealg));
> +	strscpy_pad(ap->alg_name, ealg->alg_name, sizeof(ap->alg_name));
> +	ap->alg_key_len = ealg->alg_key_len;
>  
>  	if (redact_secret && ealg->alg_key_len)
>  		memset(ap->alg_key, 0, (ealg->alg_key_len + 7) / 8);
> @@ -1043,6 +1046,40 @@ static int copy_to_user_ealg(struct xfrm_algo *ealg, struct sk_buff *skb)
>  	return 0;
>  }
>  
> +static int copy_to_user_calg(struct xfrm_algo *calg, struct sk_buff *skb)
> +{
> +	struct nlattr *nla = nla_reserve(skb, XFRMA_ALG_COMP, sizeof(*calg));
> +	struct xfrm_algo *ap;
> +
> +	if (!nla)
> +		return -EMSGSIZE;
> +
> +	ap = nla_data(nla);
> +	strscpy_pad(ap->alg_name, calg->alg_name, sizeof(ap->alg_name));
> +	ap->alg_key_len = 0;
> +
> +	return 0;
> +}
> +
> +static int copy_to_user_encap(struct xfrm_encap_tmpl *ep, struct sk_buff *skb)
> +{
> +	struct nlattr *nla = nla_reserve(skb, XFRMA_ALG_COMP, sizeof(*ep));

XFRMA_ENCAP

> +	struct xfrm_encap_tmpl *uep;
> +
> +	if (!nla)
> +		return -EMSGSIZE;
> +
> +	uep = nla_data(nla);
> +	memset(uep, 0, sizeof(*uep));
> +
> +	uep->encap_type = ep->encap_type;
> +	uep->encap_sport = ep->encap_sport;
> +	uep->encap_dport = ep->encap_dport;
> +	uep->encap_oa = ep->encap_oa;

Should that be a memcpy? At least that's how xfrm_user.c usually does
copies of xfrm_address_t.

> +
> +	return 0;
> +}
> +
>  static int xfrm_smark_put(struct sk_buff *skb, struct xfrm_mark *m)
>  {
>  	int ret = 0;
> @@ -1098,12 +1135,12 @@ static int copy_to_user_state_extra(struct xfrm_state *x,
>  			goto out;
>  	}
>  	if (x->calg) {
> -		ret = nla_put(skb, XFRMA_ALG_COMP, sizeof(*(x->calg)), x->calg);
> +		ret = copy_to_user_calg(x->calg, skb);
>  		if (ret)
>  			goto out;
>  	}
>  	if (x->encap) {
> -		ret = nla_put(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap);
> +		ret = copy_to_user_encap(x->encap, skb);
>  		if (ret)
>  			goto out;
>  	}
> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 

-- 
Sabrina


  reply	other threads:[~2023-02-08 13:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-04 17:50 [PATCH] af_key: Fix heap information leak Hyunwoo Kim
2023-02-07  6:04 ` Herbert Xu
2023-02-08  8:54   ` Hyunwoo Kim
2023-02-08 10:24     ` [PATCH] xfrm: Zero padding when dumping algos and encap Herbert Xu
2023-02-08 13:15       ` Sabrina Dubroca [this message]
2023-02-08 23:08         ` Herbert Xu
2023-02-09  5:34           ` Hyunwoo Kim
2023-02-09  8:12             ` Herbert Xu
2023-02-09  1:09       ` [v2 PATCH] " Herbert Xu
2023-02-09 14:02         ` Sabrina Dubroca
2023-02-14 13:06           ` Steffen Klassert
2023-02-09  9:16 ` [PATCH v2] af_key: Fix heap information leak Hyunwoo Kim
2023-02-09 13:52   ` Sabrina Dubroca
2023-02-13  9:40   ` patchwork-bot+netdevbpf

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=Y+Oggx0YBA3kLLcw@hog \
    --to=sd@queasysnail.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=imv4bel@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.com \
    --cc=v4bel@theori.io \
    /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 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).