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. 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 > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
