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, ®ion,
> 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
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.