[PATCH 0/7] vfio: mmap()/mprotect() hygiene for MMIO region mappings

[PATCH 0/7] vfio: mmap()/mprotect() hygiene for MMIO region mappings

[Abdifatah Suruur]

These seven patches are hygiene/hardening cleanups of the MMIO region
mmap() paths in vfio-platform, vfio/fsl-mc and vfio/cdx, all in the
same class as commit a5edadbae57e ("ptp: vmclock: prevent read-only
mappings from becoming writable").  They do two things:

 1. Clear VM_MAYWRITE on regions without VFIO_REGION_INFO_FLAG_WRITE
    so that mprotect() cannot upgrade a read-only MMIO mapping to
    writable (patches 1-3).

 2. Keep vma->vm_pgoff in the logical VFIO offset space instead of
    overwriting it with the physical frame number, and reject
    non-shared mmaps where the remap_pfn_range() COW special case
    would overwrite it anyway (patches 4-7).

Proper scoping: no in-tree platform, fsl-mc or cdx device currently
publishes a region without the WRITE flag, and none of the three
drivers calls unmap_mapping_range(), so none of these issues is
reachable today.  The vm_pgoff changes preserve the documented VFIO
core contract that every device mmap is linked to the device inode's
i_mapping so it can be revoked; that shared namespace came from
commit b7c5e64fecfa ("vfio: Create vfio_fs_type with inode per device"), so
Fixes: tags were dropped from patches 4-7 and kept on patches 1-3,
pointing at the commits that added each driver's MMIO mmap support.

Previously posted as standalone patches; grouping them into one series
per Alex's request.  Reviewed-by tags from those reviews are carried
on the affected patches.

Abdifatah Suruur (7):
  vfio/platform: prevent read-only region mappings from becoming
    writable
  vfio/fsl-mc: prevent read-only region mappings from becoming
    writable
  vfio/cdx: prevent read-only region mappings from becoming writable
  vfio/platform: keep logical vm_pgoff in MMIO region mmap
  vfio/fsl-mc: keep logical vm_pgoff in MMIO region mmap
  vfio/cdx: keep logical vm_pgoff in MMIO region mmap
  vfio/cdx: reject non-shared MMIO mmaps

 drivers/vfio/cdx/main.c                      | 11 +++++++++--
 drivers/vfio/fsl-mc/vfio_fsl_mc.c            |  9 ++++++---
 drivers/vfio/platform/vfio_platform_common.c | 15 +++++++++------
 3 files changed, 24 insertions(+), 11 deletions(-)

[PATCH 1/7] vfio/platform: prevent read-only region mappings from becoming writable

[Abdifatah Suruur]

vfio_platform_mmap() rejects writable mappings of regions without the
WRITE flag, but leaves VM_MAYWRITE set.  Userspace can map such a region
read-only and then upgrade the mapping to writable with mprotect().

Clear VM_MAYWRITE for regions without the WRITE flag, as i915 does for
its read-only objects and as fixed in drm/vc4 (CVE-2026-68445),
drm/panthor (CVE-2024-53071) and commit a5edadbae57e ("ptp: vmclock:
prevent read-only mappings from becoming writable").

Note this is defensive hardening: no in-tree platform driver currently
publishes a region without the WRITE flag.  The guard costs nothing and
keeps the mmap() interface honest if a read-only region ever appears.

Fixes: fad4d5b1f042 ("vfio/platform: support MMAP of MMIO regions")
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Reviewed-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
---
 drivers/vfio/platform/vfio_platform_common.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
index c72db5a99ebda..ab531318f170a 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -591,9 +591,13 @@ int vfio_platform_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
 			&& (vma->vm_flags & VM_READ))
 		return -EINVAL;

-	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE)
-			&& (vma->vm_flags & VM_WRITE))
-		return -EINVAL;
+	/* Prevent read-only region mappings from being upgraded with mprotect() */
+	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE)) {
+		if (vma->vm_flags & VM_WRITE)
+			return -EINVAL;
+
+		vm_flags_clear(vma, VM_MAYWRITE);
+	}

 	vma->vm_private_data = vdev;

[PATCH 2/7] vfio/fsl-mc: prevent read-only region mappings from becoming writable

[Abdifatah Suruur]

vfio_fsl_mc_mmap() rejects writable mappings of regions without the
WRITE flag, but leaves VM_MAYWRITE set.  Userspace can map such a region
read-only and then upgrade the mapping to writable with mprotect().

Clear VM_MAYWRITE for regions without the WRITE flag, as i915 does for
its read-only objects and as fixed in drm/vc4 (CVE-2026-68445),
drm/panthor (CVE-2024-53071) and commit a5edadbae57e ("ptp: vmclock:
prevent read-only mappings from becoming writable").

Note this is defensive hardening: the fsl-mc bus publishes all device
regions with the WRITE flag set, so no device can currently reach the
read-only path.  The guard costs nothing and keeps the mmap() interface
honest if a read-only region ever appears.

Fixes: 67247289688d4 ("vfio/fsl-mc: Allow userspace to MMAP fsl-mc device MMIO regions")
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -406,7 +406,11 @@
 	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE)
 			&& (vma->vm_flags & VM_WRITE))
 		return -EINVAL;

+	/* Prevent read-only region mappings from being upgraded with mprotect() */
+	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE))
+		vm_flags_clear(vma, VM_MAYWRITE);
+
 	vma->vm_private_data = mc_dev;

 	return vfio_fsl_mc_mmap_mmio(vdev->regions[index], vma);
 }

Re: [PATCH 2/7] vfio/fsl-mc: prevent read-only region mappings from becoming writable

[Alex Williamson]

On Mon, 21 Sep 2026 15:23:29 +0300
Abdifatah Suruur <suruurism@gmail.com> wrote:

> vfio_fsl_mc_mmap() rejects writable mappings of regions without the
> WRITE flag, but leaves VM_MAYWRITE set.  Userspace can map such a region
> read-only and then upgrade the mapping to writable with mprotect().
> 
> Clear VM_MAYWRITE for regions without the WRITE flag, as i915 does for
> its read-only objects and as fixed in drm/vc4 (CVE-2026-68445),
> drm/panthor (CVE-2024-53071) and commit a5edadbae57e ("ptp: vmclock:
> prevent read-only mappings from becoming writable").
> 
> Note this is defensive hardening: the fsl-mc bus publishes all device
> regions with the WRITE flag set, so no device can currently reach the
> read-only path.  The guard costs nothing and keeps the mmap() interface
> honest if a read-only region ever appears.
> 
> Fixes: 67247289688d4 ("vfio/fsl-mc: Allow userspace to MMAP fsl-mc device MMIO regions")
> Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> ---

There should be a diffstat here, check your git format-patch tooling.

> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -406,7 +406,11 @@
>  	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE)
>  			&& (vma->vm_flags & VM_WRITE))
>  		return -EINVAL;
> 
> +	/* Prevent read-only region mappings from being upgraded with mprotect() */
> +	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE))
> +		vm_flags_clear(vma, VM_MAYWRITE);
> +

Pranjal's suggestion for removing the duplicate flag test on the
platform patch should be applied here, and to the next patch for cdx as
well.  Thanks,

Alex

>  	vma->vm_private_data = mc_dev;
> 
>  	return vfio_fsl_mc_mmap_mmio(vdev->regions[index], vma);
>  }

[PATCH 3/7] vfio/cdx: prevent read-only region mappings from becoming writable

[Abdifatah Suruur]

vfio_cdx_mmap() rejects writable mappings of regions without the WRITE
flag, but leaves VM_MAYWRITE set.  Userspace can map such a region
read-only and then upgrade the mapping to writable with mprotect(),
writing to MMIO regions the device marks read-only.

Clear VM_MAYWRITE for regions without the WRITE flag, as i915 does for
its read-only objects and as fixed in drm/vc4 (CVE-2026-68445),
drm/panthor (CVE-2024-53071) and commit a5edadbae57e ("ptp: vmclock:
prevent read-only mappings from becoming writable").

Note this is defensive hardening: no in-tree cdx device currently
publishes a region without the WRITE flag.  The guard costs nothing and
keeps the mmap() interface honest if a read-only region ever appears.

Fixes: 234489ac56130 ("vfio/cdx: add support for CDX bus")
Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
---
--- a/drivers/vfio/cdx/main.c
+++ b/drivers/vfio/cdx/main.c
@@ -284,5 +284,9 @@
 	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE) &&
 	    (vma->vm_flags & VM_WRITE))
 		return -EPERM;

+	/* Prevent read-only region mappings from being upgraded with mprotect() */
+	if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE))
+		vm_flags_clear(vma, VM_MAYWRITE);
+
 	return vfio_cdx_mmap_mmio(vdev->regions[index], vma);
 }

[PATCH 4/7] vfio/platform: keep logical vm_pgoff in MMIO region mmap

[Abdifatah Suruur]

vfio_platform_mmap_mmio() overwrites vma->vm_pgoff with the physical
frame number of the MMIO region and passes it to remap_pfn_range().
The VMA is inserted into the device file's mapping->i_mmap interval
tree keyed by vm_pgoff, which VFIO expects to be the logical file
offset: the core links every device mmap to the device inode's
i_mapping precisely so that unmap_mapping_range() can revoke all
mappings associated with a device (see vfio_device_cdev_open()).

With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
coordinate space and unmap_mapping_range() cannot find the VMA,
leaving stale MMIO mappings behind any revocation attempt.  Keep
vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
the physical PFN to remap_pfn_range() explicitly.

This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
vfio/cdx call unmap_mapping_range() today, so no reachable
stale-mapping issue exists.  Keeping vm_pgoff logical preserves the
VFIO core contract for any future revocation path.

Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
---
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -561,6 +561,5 @@
 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-	vma->vm_pgoff = (region.addr >> PAGE_SHIFT) + pgoff;
-
-	return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
+	return remap_pfn_range(vma, vma->vm_start,
+			       (region.addr >> PAGE_SHIFT) + pgoff,
 			       req_len, vma->vm_page_prot);
 }

Re: [PATCH 4/7] vfio/platform: keep logical vm_pgoff in MMIO region mmap

[Alex Williamson]

On Mon, 21 Sep 2026 15:23:31 +0300
Abdifatah Suruur <suruurism@gmail.com> wrote:

> vfio_platform_mmap_mmio() overwrites vma->vm_pgoff with the physical
> frame number of the MMIO region and passes it to remap_pfn_range().
> The VMA is inserted into the device file's mapping->i_mmap interval
> tree keyed by vm_pgoff, which VFIO expects to be the logical file
> offset: the core links every device mmap to the device inode's
> i_mapping precisely so that unmap_mapping_range() can revoke all
> mappings associated with a device (see vfio_device_cdev_open()).
> 
> With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
> coordinate space and unmap_mapping_range() cannot find the VMA,
> leaving stale MMIO mappings behind any revocation attempt.  Keep
> vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
> the physical PFN to remap_pfn_range() explicitly.
> 
> This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
> vfio/cdx call unmap_mapping_range() today, so no reachable
> stale-mapping issue exists.  Keeping vm_pgoff logical preserves the
> VFIO core contract for any future revocation path.
> 
> Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
> ---
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -561,6 +561,5 @@
>  	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> -	vma->vm_pgoff = (region.addr >> PAGE_SHIFT) + pgoff;
> -
> -	return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> +	return remap_pfn_range(vma, vma->vm_start,
> +			       (region.addr >> PAGE_SHIFT) + pgoff,
>  			       req_len, vma->vm_page_prot);
>  }

Eric had provided a Reviewed-by in [1], I think the only difference is
the commit log, including dropping the Fixes: tag since it's not
currently reachable.  I'd keep the R-b for that, or he can re-add it on
the next spin.  Thanks,

Alex

[1]https://lore.kernel.org/all/21fda51a-6974-487d-874a-387dd73e2346@redhat.com/

Re: [PATCH 4/7] vfio/platform: keep logical vm_pgoff in MMIO region mmap

[Eric Auger]

On 9/29/26 1:00 AM, Alex Williamson wrote:
> On Mon, 21 Sep 2026 15:23:31 +0300
> Abdifatah Suruur <suruurism@gmail.com> wrote:
>
>> vfio_platform_mmap_mmio() overwrites vma->vm_pgoff with the physical
>> frame number of the MMIO region and passes it to remap_pfn_range().
>> The VMA is inserted into the device file's mapping->i_mmap interval
>> tree keyed by vm_pgoff, which VFIO expects to be the logical file
>> offset: the core links every device mmap to the device inode's
>> i_mapping precisely so that unmap_mapping_range() can revoke all
>> mappings associated with a device (see vfio_device_cdev_open()).
>>
>> With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
>> coordinate space and unmap_mapping_range() cannot find the VMA,
>> leaving stale MMIO mappings behind any revocation attempt.  Keep
>> vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
>> the physical PFN to remap_pfn_range() explicitly.
>>
>> This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
>> vfio/cdx call unmap_mapping_range() today, so no reachable
>> stale-mapping issue exists.  Keeping vm_pgoff logical preserves the
>> VFIO core contract for any future revocation path.
>>
>> Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
>> ---
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -561,6 +561,5 @@
>>  	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>> -	vma->vm_pgoff = (region.addr >> PAGE_SHIFT) + pgoff;
>> -
>> -	return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
>> +	return remap_pfn_range(vma, vma->vm_start,
>> +			       (region.addr >> PAGE_SHIFT) + pgoff,
>>  			       req_len, vma->vm_page_prot);
>>  }
> Eric had provided a Reviewed-by in [1], I think the only difference is
> the commit log, including dropping the Fixes: tag since it's not
> currently reachable.  I'd keep the R-b for that, or he can re-add it on
> the next spin.  Thanks,
I do agree. Feel free to keep the R-b

Eric
>
> Alex
>
> [1]https://lore.kernel.org/all/21fda51a-6974-487d-874a-387dd73e2346@redhat.com/
>

[PATCH 5/7] vfio/fsl-mc: keep logical vm_pgoff in MMIO region mmap

[Abdifatah Suruur]

vfio_fsl_mc_mmap_mmio() overwrites vma->vm_pgoff with the physical
frame number of the MMIO region and passes it to remap_pfn_range().
The VMA is inserted into the device file's mapping->i_mmap interval
tree keyed by vm_pgoff, which VFIO expects to be the logical file
offset: the core links every device mmap to the device inode's
i_mapping precisely so that unmap_mapping_range() can revoke all
mappings associated with a device (see vfio_device_cdev_open()).

With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
coordinate space and unmap_mapping_range() cannot find the VMA,
leaving stale MMIO mappings behind any revocation attempt.  Keep
vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
the physical PFN to remap_pfn_range() explicitly.

This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
vfio/cdx call unmap_mapping_range() today, so no reachable
stale-mapping issue exists.  Keeping vm_pgoff logical preserves the
VFIO core contract for any future revocation path.

Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -369,8 +369,7 @@
 	if (!region_cacheable)
 		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

-	vma->vm_pgoff = (region.addr >> PAGE_SHIFT) + pgoff;
-
-	return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
+	return remap_pfn_range(vma, vma->vm_start,
+			       (region.addr >> PAGE_SHIFT) + pgoff,
 			       size, vma->vm_page_prot);
 }

[PATCH 6/7] vfio/cdx: keep logical vm_pgoff in MMIO region mmap

[Abdifatah Suruur]

vfio_cdx_mmap_mmio() overwrites vma->vm_pgoff with the physical frame
number of the MMIO region and passes it to io_remap_pfn_range().  The
VMA is inserted into the device file's mapping->i_mmap interval tree
keyed by vm_pgoff, which VFIO expects to be the logical file offset:
the core links every device mmap to the device inode's i_mapping
precisely so that unmap_mapping_range() can revoke all mappings
associated with a device (see vfio_device_cdev_open()).

With a raw PFN in vm_pgoff the interval tree entry lands in the wrong
coordinate space and unmap_mapping_range() cannot find the VMA,
leaving stale MMIO mappings behind any revocation attempt.  Keep
vm_pgoff in the logical VFIO offset space, as vfio-pci does, and pass
the physical PFN to io_remap_pfn_range() explicitly.

This is defensive hygiene: none of vfio-platform, vfio/fsl-mc and
vfio/cdx call unmap_mapping_range() today, so no reachable
stale-mapping issue exists.  Keeping vm_pgoff logical preserves the
VFIO core contract for any future revocation path.

Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
---
--- a/drivers/vfio/cdx/main.c
+++ b/drivers/vfio/cdx/main.c
@@ -257,6 +257,6 @@
-	vma->vm_pgoff = (region.addr >> PAGE_SHIFT) + pgoff;
 	vma->vm_page_prot = pgprot_device(vma->vm_page_prot);

-	return io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
+	return io_remap_pfn_range(vma, vma->vm_start,
+				  (region.addr >> PAGE_SHIFT) + pgoff,
 				  size, vma->vm_page_prot);
 }

[PATCH 7/7] vfio/cdx: reject non-shared MMIO mmaps

[Abdifatah Suruur]

vfio_cdx_mmap() accepts MAP_PRIVATE mappings.  A non-shared mapping
with VM_MAYWRITE is a COW mapping, and remap_pfn_range()'s COW special
case in get_remap_pgoff() then overwrites vma->vm_pgoff with the
physical frame number:

	if (is_cow) {
		if (addr != vm_start || end != vm_end)
			return -EINVAL;
		*vm_pgoff_p = pfn;
	}

The VMA is inserted into the device file's mapping->i_mmap interval
tree keyed by vm_pgoff, which VFIO expects to be the logical file
offset: the core links every device mmap to the device inode's
i_mapping precisely so that unmap_mapping_range() can revoke all
mappings associated with a device (see vfio_device_cdev_open()).

A raw PFN in vm_pgoff lands the interval tree entry in the wrong
coordinate space, so unmap_mapping_range() cannot find the VMA and a
stale MMIO mapping survives any revocation attempt.  Without this
check, a MAP_PRIVATE mapping reintroduces that corruption even with
the logical-vm_pgoff fix in place.

Require VM_SHARED as vfio-pci, vfio/fsl-mc and vfio/platform already
do.  This is defensive hygiene: vfio-cdx does not call
unmap_mapping_range() today, so no reachable stale-mapping issue
exists.

Signed-off-by: Abdifatah Suruur <suruurism@gmail.com>
---
diff --git a/drivers/vfio/cdx/main.c b/drivers/vfio/cdx/main.c
index b31ed4be7bdc1..6d208db0896d6 100644
--- a/drivers/vfio/cdx/main.c
+++ b/drivers/vfio/cdx/main.c
@@ -271,6 +271,9 @@ static int vfio_cdx_mmap(struct vfio_device *core_vdev,

 	index = vma->vm_pgoff >> (VFIO_CDX_OFFSET_SHIFT - PAGE_SHIFT);

+	if (!(vma->vm_flags & VM_SHARED))
+		return -EINVAL;
+
 	if (index >= cdx_dev->res_count)
 		return -EINVAL;