Currently KASAN is incompatible with VMAP_STACK and stack overflows silently smash whatever happens to be after the stack. For some context see: https://groups.google.com/d/msg/kasan-dev/6_HoycR3p5Y/lj66K9iRBAAJ And for actual bug where it happened and caused a WARNING in rcu subsystem: https://groups.google.com/d/msg/syzkaller-bugs/HoRZMT92WKk/X6ETBRMSEAAJ 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): commit 0609ae011deb41c9629b7f5fd626dfa1ac9d16b0 Author: Daniel Axtens Date: Sat Nov 30 17:55:00 2019 -0800 x86/kasan: support KASAN_VMALLOC