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
next prev parent 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).