Re: [PATCH v2 1/2] mm: kmsan: fix iounmap metadata teardown

[Alexander Potapenko]

On Fri, Oct 2, 2026 at 11:12 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri,  2 Oct 2026 23:05:07 +0300 Dima Koziuk <dmytrokoziuk68@xxxxxxxxx> wrote:
>
> > kmsan_vmalloc_to_page_or_null() rejects addresses outside the regular
> > vmalloc and module ranges, including the shadow and origin addresses
> > passed by its callers. As a result, iounmap does not free the metadata
> > backing pages. Also, the first iteration of the teardown loop
> > unmaps the entire metadata range, preventing subsequent iterations from
> > finding their pages even if the address lookup is fixed.
> >
> > Factor the page-table walk out of vmalloc_to_page() into
> > __vmalloc_to_page(), keeping the address check in the public wrapper.
> > Use the unchecked helper in kmsan_vmalloc_to_page_or_null() and check
> > for NULL before converting the returned page to a PFN. Mark
> > __vmalloc_to_page() as __always_inline to avoid an additional function
> > call in vmalloc_to_page().
> >
> > Move metadata teardown into kmsan_iounmap_pages(). Free the backing
> > blocks while their mappings are still available, then unmap each
> > metadata range once and flush its TLB entries.
>
> Thanks, I'll queue these for test and further review.
>
> Could people please offer opinions on whether we should backport
> one/both into -stable kernels?
>

This bug is quite old, and it only causes leaks in a KMSAN build. So
stable backports are probably not needed.