* Re: kernel panic: corrupted stack end in dput
2019-07-03 15:45 ` kernel panic: corrupted stack end in dput Eric Biggers
@ 2019-07-03 16:14 ` John Fastabend
0 siblings, 0 replies; 2+ messages in thread
From: John Fastabend @ 2019-07-03 16:14 UTC (permalink / raw)
To: Eric Biggers, Al Viro
Cc: Hillf Danton, syzbot, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
syzkaller-bugs@googlegroups.com, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Yonghong Song, bpf,
Boris Pismenny, Aviad Yehezkel, Dave Watson, John Fastabend
Eric Biggers wrote:
> [+bpf and tls maintainers]
>
> On Wed, Jul 03, 2019 at 04:23:34PM +0100, Al Viro wrote:
> > On Wed, Jul 03, 2019 at 03:40:00PM +0100, Al Viro wrote:
> > > On Wed, Jul 03, 2019 at 02:43:07PM +0800, Hillf Danton wrote:
> > >
> > > > > This is very much *NOT* fine.
> > > > > 1) trylock can fail from any number of reasons, starting
> > > > > with "somebody is going through the hash chain doing a lookup on
> > > > > something completely unrelated"
> > > >
> > > > They are also a red light that we need to bail out of spiraling up
> > > > the directory hierarchy imho.
> > >
> > > Translation: "let's leak the reference to parent, shall we?"
> > >
> > > > > 2) whoever had been holding the lock and whatever they'd
> > > > > been doing might be over right after we get the return value from
> > > > > spin_trylock().
> > > >
> > > > Or after we send a mail using git. I don't know.
> > > >
> > > > > 3) even had that been really somebody adding children in
> > > > > the same parent *AND* even if they really kept doing that, rather
> > > > > than unlocking and buggering off, would you care to explain why
> > > > > dentry_unlist() called by __dentry_kill() and removing the victim
> > > > > from the list of children would be safe to do in parallel with that?
> > > > >
> > > > My bad. I have to walk around that unsafety.
> > >
> > > WHAT unsafety? Can you explain what are you seeing and how to
> > > reproduce it, whatever it is?
> >
> > BTW, what makes you think that it's something inside dput() itself?
> > All I see is that at some point in the beginning of the loop body
> > in dput() we observe a buggered stack.
> >
> > Is that the first iteration through the loop? IOW, is that just
> > the place where we first notice preexisting corruption, or is
> > that something the code called from that loop does? If it's
> > a stack overflow, I would be very surprised to see it here -
> > dput() is iterative and it's called on a very shallow stack in
> > those traces.
> >
> > What happens if you e.g. turn that
> > dput(dentry);
> > in __fput() into
> > rcu_read_lock(); rcu_read_unlock(); // trigger the check
> > dput(dentry);
> >
> > and run your reporducer?
> >
>
> Please don't waste your time on this, it looks like just another report from the
> massive memory corruption in BPF and/or TLS. Look at reproducer:
>
> bpf$MAP_CREATE(0x0, &(0x7f0000000280)={0xf, 0x4, 0x4, 0x400, 0x0, 0x1}, 0x3c)
> socket$rxrpc(0x21, 0x2, 0x800000000a)
> r0 = socket$inet6_tcp(0xa, 0x1, 0x0)
> setsockopt$inet6_tcp_int(r0, 0x6, 0x13, &(0x7f00000000c0)=0x100000001, 0x1d4)
> connect$inet6(r0, &(0x7f0000000140), 0x1c)
> bpf$MAP_CREATE(0x0, &(0x7f0000000000)={0x5}, 0xfffffffffffffdcb)
> bpf$MAP_CREATE(0x2, &(0x7f0000003000)={0x3, 0x0, 0x77fffb, 0x0, 0x10020000000, 0x0}, 0x2c)
> setsockopt$inet6_tcp_TCP_ULP(r0, 0x6, 0x1f, &(0x7f0000000040)='tls\x00', 0x4)
>
> It's the same as like 20 other syzbot reports.
There is a missing synchronize_rcu we need to add and we have a race
between map_free and tls close at the moment. The race cuases us to
incorrectly set the sk->prot pointers when tls socket is closed in
this case. I've added a hook to the ULP side now that should let
the map_free reset the saved sk->prot pointers on the TLS side and
am testing this now.
The 20 syzbot reports appear to all be due to these two issues.
This has nothing to do with dput().
Thanks,
John
>
> - Eric
^ permalink raw reply [flat|nested] 2+ messages in thread