Messages in this thread | | | Date | Tue, 31 Oct 2017 04:44:49 +0000 | From | Al Viro <> | Subject | Re: Kernel crash in free_pipe_info() |
| |
On Mon, Oct 30, 2017 at 07:08:46PM -0700, Linus Torvalds wrote: > On Mon, Oct 30, 2017 at 6:19 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > > 1. The faulty addresses are all near 0000000100000000, with one exception > > of null (which is the most recent one) > > Well, they're at 8(%rax), except for that last case.
0x10(%rax)?
> And in every case (_including_ that last case), %rax has a very > interesting pattern.. That's the (bad) buf->ops pointer that was > loaded from the somehow corrupted "buf".
> So _if_ this is some kind of use-after-free thing, and the allocation > got re-used for something else, that might just be related to whatever > ends up being the offset that is filled in with the (int) error > number. > > Except the offset is that %r12*0x28+0x10, so we're talking a byte > offset of 330 bytes into the allocation, and apparently the eight > previous (0-7) iterations were fine. > > Which is really odd.
I wonder what pipe->buffers is equal to here...
> I'm not seeing anything that makes sense. I'll have to think about this. > > I'm assuming you don't have slub debugging enabled, and no way to > enable it and try to catch this?
FWIW, I would try to slap if (buf->ops && (unsigned long)buf->ops <= 0xffffffff) dump the living hell out of that thing and see what it catches...
| |