Download raw body.
stacktrace_save_utrace() should be more robust
Hello Mark,
On Thu, May 22, 2025 at 12:02:34AM +0200, Mark Kettenis wrote:
> >
> > at line 41 we do copyin() the next frame from userland.
> > at line 43 we make a note that all frames which will
> > follow must be coming from userland. So we won't
> > get eventually confused if userland stack is either
> > corrupted or its stack frame is not set up.
>
> Sure, but if the userland stack is corrupted, the copyin on line 41
> will read a frame that may also have a bogus frame pointer. So what
> may happen is that f.f_retaddr is a plausible userland return address,
> but f.f_frame point somewhere in kernel memory. In that case we'll
> end up with a copyin that tries to read from kernel memory the next
> time around. That worried me a bit, but I suppose that'll just fail
> with an EFAULT.
yes, that's my understanding. it fails with EFAULT
thank you for taking a look.
regards
sashan
stacktrace_save_utrace() should be more robust