Re: [PATCH v1] mm/kasan: Fix incorrect unpoisoning in vrealloc for KASAN

[Jiayuan Chen]

2025/12/3 07:23, "Kees Cook" <kees@xxxxxxxxxx mailto:kees@xxxxxxxxxx?to=%22Kees%20Cook%22%20%3Ckees%40kernel.org%3E > wrote:


> 
> On Fri, Nov 28, 2025 at 07:15:14PM +0800, Jiayuan Chen wrote:
> 
> > 
> > Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two
> >  issues:
> >  
> >  1. In vrealloc, we were missing the KASAN_VMALLOC_VM_ALLOC flag when
> >  unpoisoning the extended region. This flag is required to correctly
> >  associate the allocation with KASAN's vmalloc tracking.
> >  
> >  Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly
> >  sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it.
> >  vrealloc must behave consistently — especially when reusing existing
> >  vmalloc regions — to ensure KASAN can track allocations correctly.
> >  
> >  2. When vrealloc reuses an existing vmalloc region (without allocating new
> >  pages), KASAN previously generated a new tag, which broke tag-based
> >  memory access tracking. We now add a 'reuse_tag' parameter to
> >  __kasan_unpoison_vmalloc() to preserve the original tag in such cases.
> >  
> >  A new helper kasan_unpoison_vralloc() is introduced to handle this reuse
> >  scenario, ensuring consistent tag behavior during reallocation.
> >  
> >  [1]: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36
> >  
> >  Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing")
> > 
> Is this the right Fixes tag? I didn't change the kasan logic meaningfully
> in the above patch, perhaps it should be commit d699440f58ce ("mm:
> fix vrealloc()'s KASAN poisoning logic")


The tag you provide is about shrinking but the issue I encountered was about
expanding(Grow the vm_area) and kasan_unpoison_vmalloc() didn't work well with expanding.

Thanks.