[lkml]   [2021]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BUG: KASAN: stack-out-of-bounds in unwind_next_frame+0x1df5/0x2650
On Wed, Feb 3, 2021 at 7:10 PM Josh Poimboeuf <> wrote:

> This line gives a big clue:
> [160676.608966][ C4] RIP: 0010:0xffffffffc17d814c
> That address, without a function name, most likely means that it was
> running in some generated code (mostly likely BPF) when it got
> interrupted.

We do have eBPF/XDP in our environment.

> Right now, the ORC unwinder tries to fall back to frame pointers when it
> encounters generated code:
> orc = orc_find(state->signal ? state->ip : state->ip - 1);
> if (!orc)
> /*
> * As a fallback, try to assume this code uses a frame pointer.
> * This is useful for generated code, like BPF, which ORC
> * doesn't know about. This is just a guess, so the rest of
> * the unwind is no longer considered reliable.
> */
> orc = &orc_fp_entry;
> state->error = true;
> }
> Because the ORC unwinder is guessing from that point onward, it's
> possible for it to read the KASAN stack redzone, if the generated code
> hasn't set up frame pointers. So the best fix may be for the unwinder
> to just always bypass KASAN when reading the stack.
> The unwinder has a mechanism for detecting and warning about
> out-of-bounds, and KASAN is short-circuiting that.
> This should hopefully get rid of *all* the KASAN unwinder warnings, both
> crypto and networking.

It definitely worked on my dm-crypt case, and I've tried it without
your previous AVX related patch. I will apply it to our tree and
deploy to the staging KASAN environment to see how it fares with
respect to networking stacks. Feel free to ping me if I don't get back
to you with the results on Monday.

Thanks for looking into this!

 \ /
  Last update: 2021-02-04 20:00    [W:0.068 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site