Currently KASAN is incompatible with VMAP_STACK and stack overflows silently smash whatever happens to be after the stack.
For some context see:
And for actual bug where it happened and caused a WARNING in rcu subsystem:
We either need to support VMAP_STACK with KASAN, or provide some equivalent detection.
An easy but unreliable option is to poison some region at the end of the stack and hope that some stack accesses will trap on it.
A more reliable option would be to extend compiler instrumentation to probe first/last frame bytes on function entry.
A simpler and equally reliable option would be to mprotect the last stack page, but without moving it to vmap area. Yes, wastes a page, but simple to do.
This is fixed by the following commit (and some subsequent fixes):
Author: Daniel Axtens
Date: Sat Nov 30 17:55:00 2019 -0800
x86/kasan: support KASAN_VMALLOC