All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Yu Zhang" <yuz08559@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] vduse: reject non-coherent iotlb entries in the coherent fault path
Date: Sat, 08 Aug 2026 02:27:19 +0000	[thread overview]
Message-ID: <20260808022719.9E5301F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807022657.11318-1-yuz08559@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but the patch fails to completely mitigate the pre-existing arbitrary physical memory read/write vulnerability because an attacker can map the VDUSE domain file descriptor and use it to trivially bypass the new backing file check.
--

--- Patch [1]: [PATCH] vduse: reject non-coherent iotlb entries in the coherent fault path ---
commit f4c50be37a9ca120f63ebae4dfab39a075d198c4
Author: Yu Zhang <yuz08559@gmail.com>

vduse: reject non-coherent iotlb entries in the coherent fault path

This commit attempts to fix a vulnerability where non-coherent IOTLB entries
are treated as physical addresses in the coherent fault path. It introduces a
check to ensure the backing file of the IOTLB entry matches the domain's file,
assuming only valid coherent mappings use this file.

> diff --git a/drivers/vdpa/vdpa_user/iova_domain.c b/drivers/vdpa/vdpa_user/iova_domain.c
> index b6c958224b7ce..aee0ae1c408e0 100644
> --- a/drivers/vdpa/vdpa_user/iova_domain.c
> +++ b/drivers/vdpa/vdpa_user/iova_domain.c

[ ... ]

> @@ -234,6 +235,17 @@ vduse_domain_get_coherent_page(struct vduse_iova_domain *domain, u64 iova)
>  	if (!map)
>  		goto out;
>  
> +	/*
> +	 * Only coherent allocations made by this domain are backed by a real
> +	 * struct page here: their map->addr is a physical address and their
> +	 * backing file is the domain's own anon inode. Entries installed via a
> +	 * vhost IOTLB message on a use_va device instead carry a userspace
> +	 * virtual address in map->addr, and must never be fed to pfn_to_page().
> +	 */
> +	map_file = (struct vdpa_map_file *)map->opaque;
> +	if (map_file->file != domain->file)
> +		goto out;

[Severity: Critical]
This is a pre-existing issue, but does this check completely mitigate the
vulnerability?

An attacker can obtain the domain->file descriptor via the VDUSE_IOTLB_GET_FD2
ioctl and mmap() it into their address space. If they use this new virtual
address in a VHOST_IOTLB_UPDATE message, vhost_vdpa_va_map() will assign this
same domain->file to the mapping's vm_file.

When the attacker triggers a page fault on this IOVA in
vduse_domain_get_coherent_page(), map_file->file will match domain->file,
successfully passing this check. The kernel will then pass the attacker's
arbitrary virtual address to pfn_to_page(), allowing them to regain arbitrary
physical memory read/write access.

> +
>  	page = pfn_to_page((map->addr + iova - map->start) >> PAGE_SHIFT);
>  	get_page(page);
>  out:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807022657.11318-1-yuz08559@gmail.com?part=1

      reply	other threads:[~2026-08-08  2:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07  2:26 [PATCH] vduse: reject non-coherent iotlb entries in the coherent fault path Yu Zhang
2026-08-08  2:27 ` 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=20260808022719.9E5301F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yuz08559@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.