Re: [PATCH] x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] x86/ioremap: KMSAN shadow/origin page leak in __ioremap_caller()
--

commit 17e6df6da515e9dac650cd6369fda70f312c2a6a
Author: Jason Andryuk <jason.andryuk@amd.com>

x86/paravirt: Add ioremap_verify_range hook and implement it for Xen PV

This commit adds an ioremap_verify_range hook to pv_mmu_ops so __ioremap_caller() can verify that page table entries were actually mapped after ioremap_page_range(). On Xen PV, it walks the virtual address range with lookup_address() and fails if any PTE is not present, causing ioremap() to return NULL when Xen rejects mapping machine frames.

Link: https://lore.kernel.org/xen-devel/20251219010131.12659-1-ariadne@ariadne.space/

> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 12c8180ca1ba7..6b45a7eef5934 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -301,6 +301,9 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
>  	if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot))
>  		goto err_free_area;
>  
> +	if (ioremap_verify_range(vaddr, size))
> +		goto err_free_area;

[Severity: Medium]
When CONFIG_KMSAN=y is enabled, can failing ioremap_verify_range() in
__ioremap_caller() leak the KMSAN shadow and origin pages allocated by
ioremap_page_range()?

In ioremap_page_range() -> vmap_page_range(), kmsan_ioremap_page_range()
allocates and maps order-1 shadow and origin pages (which are normal guest
RAM and succeed on Xen PV even when Xen refuses the MMIO PTEs):

mm/vmalloc.c:vmap_page_range() {
	err = vmap_range_noflush(addr, end, phys_addr, pgprot_nx(prot),
				 ioremap_max_page_shift);
	flush_cache_vmap(addr, end);
	if (!err)
		err = kmsan_ioremap_page_range(addr, end, phys_addr, prot,
					       ioremap_max_page_shift);
	return err;
}

When ioremap_verify_range() subsequently fails and jumps to err_free_area,
free_vm_area(area) calls remove_vm_area() -> free_unmap_vmap_area() ->
vunmap_range_noflush() -> kmsan_vunmap_range_noflush(), which unmaps the
shadow and origin PTEs without freeing the underlying pages.

In contrast, iounmap() in arch/x86/mm/ioremap.c explicitly calls
kmsan_iounmap_page_range() before remove_vm_area() so KMSAN can look up and
free the shadow and origin pages before their PTEs are cleared:

arch/x86/mm/ioremap.c:iounmap() {
	...
	kmsan_iounmap_page_range((unsigned long)addr,
		(unsigned long)addr + get_vm_area_size(p));
	memtype_free(p->phys_addr, p->phys_addr + get_vm_area_size(p));

	/* Finally remove it */
	o = remove_vm_area((void __force *)addr);
	...
}

Should the failure path after ioremap_page_range() call
kmsan_iounmap_page_range(vaddr, vaddr + size) before free_vm_area(area)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261031003309.3751-1-jason.andryuk@amd.com?part=1