Linux-HyperV List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mukesh R" <mrathor@linux.microsoft.com>, linux-hyperv@vger.kernel.org
Subject: Re: [PATCH] mshv: Do not map mmio in map user memory ioctl
Date: Fri, 13 Nov 2026 03:24:31 +0000	[thread overview]
Message-ID: <sashiko-outbox-212132@kernel.org> (raw)
In-Reply-To: <20261113031343.896489-1-mrathor@linux.microsoft.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mshv: missing Fixes trailer on commit fixing crash in
  mshv_map_user_memory()
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [Medium] mshv: ignored mshv_region_map() error in
  mshv_prepare_pinned_region() [1]
--

commit f8208ba7fc5113c6d67967e4650125ea72fda573
Author: Mukesh R <mrathor@linux.microsoft.com>

> mshv: Do not map mmio in map user memory ioctl
>
> Currently, mshv_map_user_memory() snoops into vma to get the mmio
> pfn via vm_pgoff. The mmio pfn is no longer stored there and will
> cause the system to crash. Moreover, it is not legit to obtain
> mmio pfn via that method. So, remove upfront mmio mappings, just
> create region and do basic checks. The mmio entries will be populated
> on demand during intercepts in future.
>
> Signed-off-by: Mukesh R <mrathor@linux.microsoft.com>

[Severity: Low]
This fixes a system crash when mapping MMIO memory regions.  Should this
include:

  Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs")

> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index cc2cfce2aefdb..f1f143e32c078 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -1345,16 +1345,8 @@ static int mshv_prepare_pinned_region(struct mshv_mem_region *region)
>  }
>  
>  /*
> - * This maps two things: guest RAM and for pci passthru mmio space.
> - *
> - * mmio:
> - *  - vfio overloads vm_pgoff to store the mmio start pfn/spa.
> - *  - Two things need to happen for mapping mmio range:
> - *	1. mapped in the uaddr so VMM can access it.
> - *	2. mapped in the hwpt (gfn <-> mmio phys addr) so guest can access it.
> - *
> - *   This function takes care of the second. The first one is managed by vfio,
> - *   and hence is taken care of via vfio_pci_mmap_fault().
> + * This is called for both user ram and mmio space. The mmio space is not
> + * mapped here, that should happen later during intercept on demand.
>   */
>  static long
>  mshv_map_user_memory(struct mshv_partition *partition,
> @@ -1363,7 +1355,7 @@ mshv_map_user_memory(struct mshv_partition *partition,
>  	struct mshv_mem_region *region;
>  	struct vm_area_struct *vma;
>  	bool is_mmio;
> -	ulong mmio_pfn;
> +	size_t vma_sz;
>  	long ret;
>  
>  	if (mem->flags & BIT(MSHV_SET_MEM_BIT_UNMAP) ||
> @@ -1373,12 +1365,18 @@ mshv_map_user_memory(struct mshv_partition *partition,
>  	mmap_read_lock(current->mm);
>  	vma = vma_lookup(current->mm, mem->userspace_addr);
>  	is_mmio = vma ? !!(vma->vm_flags & (VM_IO | VM_PFNMAP)) : 0;
> -	mmio_pfn = is_mmio ? vma->vm_pgoff : 0;
> +	if (vma && is_mmio)
> +		vma_sz = vma->vm_end - mem->userspace_addr;
>  	mmap_read_unlock(current->mm);
>  
>  	if (!vma)
>  		return -EINVAL;
>  
> +	if (is_mmio)
> +		/* Upon mmio intercept, entire region is mapped */
> +		if (mem->size > vma_sz)
> +			return -EPERM;
> +
>  	ret = mshv_partition_create_region(partition, mem, &region,
>  					   is_mmio);
>  	if (ret)
> @@ -1399,11 +1397,7 @@ mshv_map_user_memory(struct mshv_partition *partition,
>  					    region->nr_pages,
>  					    HV_MAP_GPA_NO_ACCESS, NULL);
>  		break;
> -	case MSHV_REGION_TYPE_MMIO:
> -		ret = hv_call_map_mmio_pages(partition->pt_id,
> -					     region->start_gfn,
> -					     mmio_pfn,
> -					     region->nr_pages);
> +	default:
>  		break;
>  	}

[Severity: Medium]
This problem wasn't introduced by this patch, but does
mshv_prepare_pinned_region() ignore mshv_region_map() errors on
non-encrypted partitions [1]?

drivers/hv/mshv_root_main.c:mshv_prepare_pinned_region() {
    ...
	ret = mshv_region_map(region);
	if (ret && mshv_partition_encrypted(partition)) {
		int shrc;

		shrc = mshv_region_share(region);
		if (!shrc)
			goto invalidate_region;
    ...
		goto err_out;
	}

	return 0;

invalidate_region:
	mshv_region_invalidate(region);
err_out:
	return ret;
}

When mshv_region_movable_init() fails on a non-encrypted partition,
mshv_partition_create_region() falls back to MSHV_REGION_TYPE_MEM_PINNED.
If mshv_region_map() then fails, mshv_prepare_pinned_region() skips
mshv_region_invalidate() and returns 0, so mshv_map_user_memory() links the
unmapped region into partition->pt_mem_regions with its pages left pinned
and returns success to userspace.

[1] https://sashiko.dev/#/bug/linux-a3d211d1-2dbc-4947-880d-f5809ec51869

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113031343.896489-1-mrathor@linux.microsoft.com?part=1

      reply	other threads:[~2026-11-13  3:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13  3:13 [PATCH] mshv: Do not map mmio in map user memory ioctl Mukesh R
2026-11-13  3:24 ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-212132@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=mrathor@linux.microsoft.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox