All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Fred Griffoul" <griffoul@gmail.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	"Oliver Upton" <oupton@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>
Subject: Re: [RFC PATCH v2 08/11] iommufd/selftest: Add mock-domain IOVA queries
Date: Wed, 14 Oct 2026 09:54:47 +0000	[thread overview]
Message-ID: <sashiko-outbox-171101@kernel.org> (raw)
In-Reply-To: <20261014093733.90312-9-griffoul@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] iommufd: soft lockup in iommufd_test_md_check_mapped loop
- [Medium] iommufd: UAF race between mock page table walk and dma-buf revoke
--

commit 64ca9f35d00cc158de5f4700e220a39eb8a04615
Author: Fred Griffoul <fgriffo@amazon.co.uk>

iommufd/selftest: Add mock-domain IOVA queries

A test of memory that can be taken back or replaced does not know in
advance which frame a device reaches. IOMMU_TEST_OP_MD_CHECK_MAP only
compares against a known buffer.

Add MD_CHECK_MAPPED, which checks that a range is fully mapped or fully
unmapped, and MD_IOVA_TO_PHYS, which returns the frame behind an IOVA,
or 0 if it is unmapped. Both refuse an IOVA outside the domain's
aperture.

> diff --git a/drivers/iommu/iommufd/selftest.c b/drivers/iommu/iommufd/selftest.c
> index af07c642a5260..1f5cd2d00fda8 100644
> --- a/drivers/iommu/iommufd/selftest.c
> +++ b/drivers/iommu/iommufd/selftest.c
[ ... ]
> +static int iommufd_test_md_iova_to_phys(struct iommufd_ucmd *ucmd,
> +					unsigned int mockpt_id,
> +					unsigned long iova)
> +{
> +	struct iommu_test_cmd *cmd = ucmd->cmd;
> +	struct iommufd_hw_pagetable *hwpt;
> +	struct mock_iommu_domain *mock;
> +	unsigned int page_size;
> +	int rc;
> +
> +	hwpt = get_md_pagetable(ucmd, mockpt_id, &mock);
> +	if (IS_ERR(hwpt))
> +		return PTR_ERR(hwpt);
> +
> +	page_size = 1 << __ffs(mock->domain.pgsize_bitmap);
> +	if (iova % page_size || !mock_domain_covers(mock, iova, page_size)) {
> +		rc = -EINVAL;
> +		goto out_put;
> +	}
> +	down_write(mock_domain_unmap_lock(hwpt));
> +	cmd->iova_to_phys.out_phys =
> +		mock->domain.ops->iova_to_phys(&mock->domain, iova);

[Severity: Medium]
Could this page table walk race with a concurrent dma-buf revoke or memory
provider unmap?

Since those unmap operations run under their own pages mutex instead of
domains_rwsem, it seems possible for a concurrent unmap (for instance,
triggered by a fuzzer or concurrently running test) to free a page table
level while iova_to_phys() is still walking it, potentially leading to a
use-after-free.

> +	up_write(mock_domain_unmap_lock(hwpt));
> +	rc = iommufd_ucmd_respond(ucmd, sizeof(*cmd));
> +out_put:
> +	iommufd_put_object(ucmd->ictx, &hwpt->obj);
> +	return rc;
> +}
> +
> +static int iommufd_test_md_check_mapped(struct iommufd_ucmd *ucmd,
> +					unsigned int mockpt_id,
> +					unsigned long iova, size_t length,
> +					bool mapped)
> +{
[ ... ]
> +	down_write(mock_domain_unmap_lock(hwpt));
> +	for (; length; length -= page_size, iova += page_size) {
> +		bool is_mapped =
> +			mock->domain.ops->iova_to_phys(&mock->domain, iova) != 0;

[Severity: Medium]
Can this loop run for an unbounded amount of time and cause a soft lockup?

Since the test ioctl interface allows very large values for length, and
page_size can be as small as 4096 bytes, this loop could iterate trillions
of times without yielding.

Because it holds domains_rwsem for writing, would this stall the CPU and
starve other users of the semaphore?

> +
> +		if (is_mapped != mapped) {
> +			rc = -ENOENT;
> +			break;
> +		}
> +	}
> +	up_write(mock_domain_unmap_lock(hwpt));
> +
> +out_put:
> +	iommufd_put_object(ucmd->ictx, &hwpt->obj);
> +	return rc;
> +}

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

  reply	other threads:[~2026-10-14  9:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  9:37 [RFC PATCH v2 00/11] mm: Memory providers for guest_memfd and iommufd Fred Griffoul
2026-10-14  9:37 ` [RFC PATCH v2 01/11] KVM: guest_memfd: Introduce guest memory ops and route native gmem through them Fred Griffoul
2026-10-14  9:51   ` sashiko-bot
2026-10-14  9:37 ` [RFC PATCH v2 02/11] KVM: guest_memfd: Let get_pfn() report read-only pages Fred Griffoul
2026-10-14  9:37 ` [RFC PATCH v2 03/11] mm: Add memory providers Fred Griffoul
2026-10-14  9:37 ` [RFC PATCH v2 04/11] KVM: guest_memfd: Add a memory provider backing Fred Griffoul
2026-10-14  9:37 ` [RFC PATCH v2 05/11] iommufd: Track the domains of pages that are not pinned Fred Griffoul
2026-10-14  9:37 ` [RFC PATCH v2 06/11] iommufd: Map memory provider files Fred Griffoul
2026-10-14  9:51   ` sashiko-bot
2026-10-14  9:37 ` [RFC PATCH v2 07/11] iommufd: Use large IOMMU pages for provider mappings Fred Griffoul
2026-10-14  9:37 ` [RFC PATCH v2 08/11] iommufd/selftest: Add mock-domain IOVA queries Fred Griffoul
2026-10-14  9:54   ` sashiko-bot [this message]
2026-10-14  9:37 ` [RFC PATCH v2 09/11] iommufd/selftest: Add a mock memory provider Fred Griffoul
2026-10-14  9:37 ` [RFC PATCH v2 10/11] samples/kvm: Add a memory provider sample Fred Griffoul
2026-10-14  9:50   ` sashiko-bot
2026-10-14  9:37 ` [RFC PATCH v2 11/11] KVM: selftests: Test a memory provider shared by KVM and iommufd Fred Griffoul

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-171101@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=griffoul@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --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.