[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1k4T/rgRz4rkvcl@hog>
Date: Wed, 26 Oct 2022 15:38:23 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Eric Dumazet <edumazet@...gle.com>,
syzbot <syzbot+1e9af9185d8850e2c2fa@...kaller.appspotmail.com>,
davem@...emloft.net, kuba@...nel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, pabeni@...hat.com,
steffen.klassert@...unet.com, syzkaller-bugs@...glegroups.com
Subject: Re: [v3 PATCH] af_key: Fix send_acquire race with pfkey_register
2022-10-25, 14:06:48 +0800, Herbert Xu wrote:
> On Mon, Oct 24, 2022 at 09:20:00AM +0200, Sabrina Dubroca wrote:
> > 2022-10-24, 14:06:12 +0800, Herbert Xu wrote:
> > > @@ -1697,11 +1699,11 @@ static int pfkey_register(struct sock *sk, struct sk_buff *skb, const struct sad
> > > pfk->registered |= (1<<hdr->sadb_msg_satype);
> > > }
> > >
> > > - mutex_lock(&pfkey_mutex);
> > > + spin_lock_bh(&pfkey_alg_lock);
> > > xfrm_probe_algs();
> >
> > I don't think we can do that:
> >
> > void xfrm_probe_algs(void)
> > {
> > int i, status;
> >
> > BUG_ON(in_softirq());
>
> Indeed. I was also wrong in stating that this bug was created by
> namespaces. This race has always existed since this code was first
> added.
>
> ---8<---
> The function pfkey_send_acquire may race with pfkey_register
> (which could even be in a different name space). This may result
> in a buffer overrun.
>
> Allocating the maximum amount of memory that could be used prevents
> this.
>
> Reported-by: syzbot+1e9af9185d8850e2c2fa@...kaller.appspotmail.com
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
LGTM, thanks.
Reviewed-by: Sabrina Dubroca <sd@...asysnail.net>
--
Sabrina
Powered by blists - more mailing lists