Wow, that's weird. I think that basically implies that you're hitting recursion that precisely goes deep enough to overwrite the lowest 8 bytes on the stack, but doesn't access anything below those 8 bytes... On Thu, Aug 29, 2024 at 10:29 PM Juefei Pu <juefei.pu@xxxxxxxxxxxxx> wrote: > > Hi Jann, > > I checked the kernel configuration we used and I found that we did > enable CONFIG_KASAN_VMALLOC and CONFIG_VMAP_STACK during fuzzing. > I've uploaded the full configuration to > https://gist.github.com/TomAPU/64f5db0fe976a3e94a6dd2b621887cdd > > On Thu, Aug 29, 2024 at 1:23 PM Jann Horn <jannh@xxxxxxxxxx> wrote: > > > > On Wed, Aug 28, 2024 at 1:49 AM Juefei Pu <juefei.pu@xxxxxxxxxxxxx> wrote: > > > Hello, > > > We found the following issue using syzkaller on Linux v6.10. > > > The PoC generated by Syzkaller can have the kernel panic. > > > The full report including the Syzkaller reproducer: > > > https://gist.github.com/TomAPU/a96f6ccff8be688eb2870a71ef4d035d > > > > > > The brief report is below: > > > > > > Syzkaller hit 'kernel panic: corrupted stack end in worker_thread' bug. > > > > > > Kernel panic - not syncing: corrupted stack end detected inside scheduler > > > > I assume you're fuzzing without CONFIG_VMAP_STACK? Please make sure to > > set CONFIG_VMAP_STACK=y in your kernel config, that will give much > > better diagnostics when you hit a stack overrun like this, instead of > > causing random corruption and running into the corrupted stack end > > detection. > > > > (Note that if you're using KASAN, you have to enable > > CONFIG_KASAN_VMALLOC in order for CONFIG_VMAP_STACK to work.)
