Re: [PATCH 2/2] mm: kmsan: fix ioremap error cleanup

From: Alexander Potapenko

Date: Tue Sep 29 2026 - 10:02:11 EST


On Tue, Sep 15, 2026 at 9:02 PM Dima Koziuk <dmytrokoziuk68@xxxxxxxxx> wrote:
>
> Looking further at kmsan_ioremap_page_range(), I found three cases where
> error cleanup leaks metadata blocks. Fault-injection testing confirmed
> all three:
>
> 1. If the first iteration fails, clean is zero and cleanup is skipped,
> leaking any allocations that succeeded in that iteration.
>
> 2. If shadow mapping succeeds but origin mapping fails, the shadow
> pointer has already been cleared. Removing its mapping loses the
> backing block.
>
> 3. On failures after completed iterations, cleanup removes the earlier
> metadata mappings without freeing their backing blocks.
>
> The cleanup needed here is the same as for iounmap, so it makes sense to
> reuse kmsan_iounmap_pages(). Track the end of installed mappings with
> mapped_end and advance it after each successful shadow mapping. This
> includes the current shadow block if origin mapping subsequently fails,
> while the PTE walk skips the missing origin mapping.
>
> Run cleanup whenever err is non-zero. Free allocations that have not been
> mapped directly, and use the shared helper to unmap and free the installed
> metadata, including blocks from completed iterations.
>
> Fixes: fdea03e12aa2 ("mm: kmsan: handle alloc failures in kmsan_ioremap_page_range()")
> Signed-off-by: Dima Koziuk <dmytrokoziuk68@xxxxxxxxx>
Reviewed-by: Alexander Potapenko <glider@xxxxxxxxxx>

Note that I'd rework patch 1/2 to use a non-checked version of
vmalloc_to_page() (see the other email)