[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAhDqq28h9_ji=ANttUyx2Q1Md=bZD3-JVCwQRW06W7aikPN0A@mail.gmail.com>
Date: Sun, 26 Jul 2020 11:42:43 +0530
From: B K Karthik <bkkarthik@...u.pes.edu>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: Steffen Klassert <steffen.klassert@...unet.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Jakub Kicinski <kuba@...nel.org>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>,
Shuah Khan <skhan@...uxfoundation.org>,
linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH v2] net: ipv6: fix use-after-free Read in __xfrm6_tunnel_spi_lookup
On Sun, Jul 26, 2020 at 11:05 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Sat, Jul 25, 2020 at 8:09 PM B K Karthik <bkkarthik@...u.pes.edu> wrote:
> > @@ -103,10 +103,10 @@ static int __xfrm6_tunnel_spi_check(struct net *net, u32 spi)
> > {
> > struct xfrm6_tunnel_net *xfrm6_tn = xfrm6_tunnel_pernet(net);
> > struct xfrm6_tunnel_spi *x6spi;
> > - int index = xfrm6_tunnel_spi_hash_byspi(spi);
> > + int index = xfrm6_tunnel_spi_hash_byaddr((const xfrm_address_t *)spi);
> >
> > hlist_for_each_entry(x6spi,
> > - &xfrm6_tn->spi_byspi[index],
> > + &xfrm6_tn->spi_byaddr[index],
> > list_byspi) {
> > if (x6spi->spi == spi)
>
> How did you convince yourself this is correct? This lookup is still
> using spi. :)
I'm sorry, but my intention behind writing this patch was not to fix
the UAF, but to fix a slab-out-of-bound.
If required, I can definitely change the subject line and resend the
patch, but I figured this was correct for
https://syzkaller.appspot.com/bug?id=058d05f470583ab2843b1d6785fa8d0658ef66ae
. since that particular report did not have a reproducer,
Dmitry Vyukov <dvyukov@...gle.com> suggested that I test this patch on
other reports for xfrm/spi .
Forgive me if this was the wrong way to send a patch for that
particular report, but I guessed since the reproducer did not trigger
the crash
for UAF, I would leave the subject line as 'fix UAF' :)
xfrm6_spi_hash_by_hash seemed more convincing because I had to prevent
a slab-out-of-bounds because it uses ipv6_addr_hash.
It would be of great help if you could help me understand how this was
able to fix a UAF.
>
> More importantly, can you explain how UAF happens? Apparently
> the syzbot stack traces you quote make no sense at all. I also
> looked at other similar reports, none of them makes sense to me.
Forgive me, but I do not understand what you mean by the stack traces
(this or other similar reports) "make no sense".
I apologise if this message was hurtful / disrespectful in any manner.
thanks,
karthik
Powered by blists - more mailing lists