[Crash-utility] arm64: bug report: segfault

[Andrew Jones]

On Mon, Dec 21, 2015 at 08:37:25AM -0500, Dave Anderson wrote:
> 
> 
> Hi Drew,
> 
> I am out of the office until Jan 4th, so I may not get around to checking
> this out fully until then.  But in the meantime, can you save this dumpfile
> and send me a pointer to it offline?  I want to keep it around for future
> testing.

OK, I've got a 90MB kdump-zlib core I can put somewhere. I don't know
where though, other than just telling you where in RH's network you can
grab it from. Also the vmlinux associated with it is one of my own
builds, basically a RHELSA kernel, but with 4K pages (4K pages needed in
order to use 32-bit user binaries).

Thanks,
drew

> 
> Thanks,
>   Dave
> 
> 
> ----- Original Message -----
> > Hi Dave,
> > 
> > When crash gets a prstatus for an AArch32 (compat) user mode stack frame,
> > but assumes it can look at prstatus->sp for the stack pointer, and
> > prstatus->sp has a stale AArch64 kernel address in it, then crash
> > segfaults.
> > 
> > This is because the stack pointer isn't a user stack address, and thus
> > crash expects the stack to include at least two frames, which would mean
> > fp is non-zero, but in this case it's not[1], and that leads to the
> > calculation of a bad stack pointer (see arm64.c:1209), which then gets
> > used as an offset into the stack buffer (see arm64.c:1001), overflowing
> > it.
> > 
> > The patch[2] I just sent resolves this issue for me, but only because
> > it no longer tries to use prstatus->sp. We should probably still look
> > into fixing this in another way, such as making sure fp is non-zero, as
> > dumps can have all sorts of corruption breaking our assumptions.
> > 
> > Thanks,
> > drew
> > 
> > [1] The dump was captured with QEMU, which doesn't require a real crash,
> >     i.e. panic() being called in the guest kernel, thus cpus can actually
> >     be in user mode, rather than in the 64-bit cpu-stop IPI handler, or
> >     other crashing kernel code.
> > [2] https://www.redhat.com/archives/crash-utility/2015-December/msg00024.html
> >