From: sashiko-bot@kernel.org
To: "Abdifatah Suruur" <suruurism@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] vfio/cdx: prevent read-only region mappings from becoming writable
Date: Wed, 19 Aug 2026 08:58:29 +0000 [thread overview]
Message-ID: <20260819085830.21D5F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260819084203.1526-1-suruurism@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing VM_SHARED check in vfio_cdx_mmap allows COW on device MMIO memory.
- [High] Missing VM_MAYWRITE clearing allows read-only VFIO platform and fsl-mc regions to be upgraded to writable via mprotect.
--
--- Patch [1]: [PATCH] vfio/cdx: prevent read-only region mappings from becoming writable ---
commit 83f86639f8fdaf3a6302850a1c0944c947af0f5c
Author: Abdifatah Suruur <suruurism@gmail.com>
vfio/cdx: prevent read-only region mappings from becoming writable
This commit clears the VM_MAYWRITE flag in vfio_cdx_mmap() for regions
without the WRITE flag. This prevents userspace from upgrading read-only
mappings to writable using mprotect().
Cc: stable@vger.kernel.org
> diff --git a/drivers/vfio/cdx/main.c b/drivers/vfio/cdx/main.c
> index b31ed4be7bdc1..b6b17a6a46811 100644
> --- a/drivers/vfio/cdx/main.c
> +++ b/drivers/vfio/cdx/main.c
> @@ -285,6 +285,10 @@ static int vfio_cdx_mmap(struct vfio_device *core_vdev,
> (vma->vm_flags & VM_WRITE))
> return -EPERM;
[Severity: High]
This is a pre-existing issue, but does vfio_cdx_mmap() also need to reject
mappings that lack VM_SHARED?
If a user maps the region with MAP_PRIVATE, a write fault will trigger a
Copy-On-Write (COW). The COW reads from the device MMIO using bulk memory
instructions (via __wp_page_copy_user()), which could cause unsupported bus
transactions (like SError on ARM64) and crash the system. Additionally,
writes to the mapping will quietly hit RAM instead of the device, breaking
MMIO semantics.
Unlike other VFIO bus drivers, this function appears to be missing a
validation check to reject private mappings. Could the absence of a
`(vma->vm_flags & VM_SHARED) == 0` check here allow users to inadvertently
trigger these COW crashes?
>
> + /* 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);
> +
[Severity: High]
This isn't a bug introduced by this patch, but does the same vulnerability
exist in other vfio drivers?
Looking at vfio_platform_mmap() in drivers/vfio/platform/vfio_platform_common.c
and vfio_fsl_mc_mmap() in drivers/vfio/fsl-mc/vfio_fsl_mc.c, both check for
VM_WRITE but neither explicitly clears VM_MAYWRITE.
If those drivers leave VM_MAYWRITE set, could they also allow users to upgrade
read-only regions to writable via mprotect() in the same way being fixed here?
> return vfio_cdx_mmap_mmio(vdev->regions[index], vma);
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260819084203.1526-1-suruurism@gmail.com?part=1
next prev parent reply other threads:[~2026-08-19 8:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 8:42 [PATCH] vfio/cdx: prevent read-only region mappings from becoming writable Abdifatah Suruur
2026-08-19 8:58 ` sashiko-bot [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-08-19 8:39 Abdifatah Suruur
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=20260819085830.21D5F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=suruurism@gmail.com \
/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.