[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+QriSfj3OYBj6J6@gondor.apana.org.au>
Date: Thu, 9 Feb 2023 07:08:57 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: Hyunwoo Kim <v4bel@...ori.io>, steffen.klassert@...unet.com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, imv4bel@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] xfrm: Zero padding when dumping algos and encap
On Wed, Feb 08, 2023 at 02:15:47PM +0100, Sabrina Dubroca wrote:
>
> 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.
It's meant to be a replacement but yes we should still zero x->encap
because that will leak out in other ways, e.g., on the wire.
Hyunwoo, could you please repost your patch just for x->encap?
> > +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
Good catch. I will repost the patch.
> > + 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.
It doesn't really matter.
Thanks,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists