netdev - Re: [PATCH] xfrm: Zero padding when dumping algos and encap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230209053416.GA5032@ubuntu>
Date:   Wed, 8 Feb 2023 21:34:16 -0800
From:   Hyunwoo Kim <v4bel@...ori.io>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Sabrina Dubroca <sd@...asysnail.net>, steffen.klassert@...unet.com,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, v4bel@...ori.io, imv4bel@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH] xfrm: Zero padding when dumping algos and encap

On Thu, Feb 09, 2023 at 07:08:57AM +0800, Herbert Xu wrote:
> 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?

Can the x->encap patch do this?

I didn't add the syzbot hash as x->encap is not the flow reported by syzbot:
Subject: [PATCH] af_key: Fix heap information leak

Since x->encap of pfkey_msg2xfrm_state() is not
initialized to 0, kernel heap data can be leaked.

Fix with kzalloc() to prevent this.

Signed-off-by: Hyunwoo Kim <v4bel@...ori.io>
---
 net/key/af_key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index 2bdbcec781cd..a815f5ab4c49 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1261,7 +1261,7 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
 		const struct sadb_x_nat_t_type* n_type;
 		struct xfrm_encap_tmpl *natt;

-		x->encap = kmalloc(sizeof(*x->encap), GFP_KERNEL);
+		x->encap = kzalloc(sizeof(*x->encap), GFP_KERNEL);
 		if (!x->encap) {
 			err = -ENOMEM;
 			goto out;
> 
> > > +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