From: Baolu Lu <baolu.lu@linux.intel.com>
To: Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>
Cc: baolu.lu@linux.intel.com, joro@8bytes.org,
Jason Gunthorpe <jgg@nvidia.com>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Kevin Tian <kevin.tian@intel.com>,
Jean-Philippe Brucker <jpb@kernel.org>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 3/4] iommu: Unpublish the old attach handle before the group replace callback
Date: Mon, 2 Nov 2026 14:05:26 +0800 [thread overview]
Message-ID: <e6624f1a-b6dd-4229-a26c-4b0501357b75@linux.intel.com> (raw)
In-Reply-To: <auglmP/oFZNhnja/@nvidia.com>
On 11/2/2026 1:54 PM, Nicolin Chen wrote:
> On Mon, Nov 02, 2026 at 11:30:02AM +0800, Yi Liu wrote:
>> On 11/1/26 13:53, Baolu Lu wrote:
>>> This doesn't fix the same-domain replace issue, which can still result
>>> in a use-after-free bug. I agree that this needs a separate lifetime
>>> mechanism as stated in the cover letter. But is it possible to prevent
>>> the same-domain replace case from going through this interface?
>> fwiw, iommufd already guards this at the device-replace layer
>> (iommufd_device_do_replace() short-circuits when hwpt == old_hwpt) [1],
>> so IOMMUFD callers can't currently trigger this. But that's a caller-side
>> convention, not something
>> iommu_replace_group_handle()/iommu_replace_device_pasid() enforce themselves
>> - so it's still
>> reachable if a future/other caller doesn't do the same check. Worth
>> deciding whether to push the guard down into the core API, or document
>> it as a caller contract.
> I can add a fifth patch. Please see if it looks good to you.
>
> Subject: [PATCH] iommu: Reject a same-domain replace in the attach handle APIs
>
> Both iommu_replace_group_handle() and iommu_replace_device_pasid() skip the
> driver callback when the new domain is the one currently attached. In that
> case, nothing flushes the pending faults that may still be holding the old
> handle. Then, the caller frees the old handle once the replace returns, so
> such a fault would hit a use-after-free.
>
> No caller does this today, since iommufd_device_do_replace() returns early
> when the new hwpt is the old one. However, it is only a caller convention,
> which neither API enforces.
>
> Reject a same-domain replace in both APIs with a WARN_ON, and document it
> in their kernel-docs.
>
> Suggested-by: Lu Baolu<baolu.lu@linux.intel.com>
> Signed-off-by: Nicolin Chen<nicolinc@nvidia.com>
> ---
> drivers/iommu/iommu.c | 34 +++++++++++++++++++++++++++-------
> 1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 3fea48d3538ad..a9bc4ca5dbb4e 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -3716,6 +3716,10 @@ EXPORT_SYMBOL_GPL(iommu_attach_device_pasid);
> * Caller should always provide a new handle to avoid race with the paths
> * that have lockless reference to handle if it intends to pass a valid handle.
> *
> + * The @domain must not be the domain currently attached to the @pasid. Such a
> + * same-domain replace would skip the driver callback flushing pending faults.
> + * Then, those faults could use the old handle after the caller frees it.
> + *
> * Return 0 on success, or an error.
> */
> int iommu_replace_device_pasid(struct iommu_domain *domain,
> @@ -3785,15 +3789,17 @@ int iommu_replace_device_pasid(struct iommu_domain *domain,
> }
>
> curr_domain = pasid_array_entry_to_domain(curr);
> - ret = 0;
> -
> - if (curr_domain != domain) {
> - ret = __iommu_set_group_pasid(domain, group,
> - pasid, curr_domain);
> - if (ret)
> - entry = curr; /* restore the old handle */
> + /* Same as iommu_replace_group_handle(), reject a same-domain replace */
> + if (WARN_ON(curr_domain == domain)) {
> + entry = curr; /* restore the old handle */
> + ret = -EINVAL;
> + goto out_store;
> }
>
> + ret = __iommu_set_group_pasid(domain, group, pasid, curr_domain);
> + if (ret)
> + entry = curr; /* restore the old handle */
> +
> out_store:
> /*
> * The xa_store() above reserved the memory, and the group->mutex
> @@ -3985,6 +3991,10 @@ EXPORT_SYMBOL_NS_GPL(iommu_detach_group_handle, "IOMMUFD_INTERNAL");
> *
> * Caller should always provide a new handle to avoid race with the paths
> * that have lockless reference to handle.
> + *
> + * The @new_domain must not be the domain currently attached to the group. Such
> + * a same-domain replace would skip the driver callback flushing pending faults.
> + * Then, those faults could use the old handle after the caller frees it.
> */
> int iommu_replace_group_handle(struct iommu_group *group,
> struct iommu_domain *new_domain,
> @@ -3997,6 +4007,16 @@ int iommu_replace_group_handle(struct iommu_group *group,
> return -EINVAL;
>
> mutex_lock(&group->mutex);
> + /*
> + * A same-domain replace would skip the driver callback flushing pending
> + * faults. Then, those faults could use the old handle after the caller
> + * frees it.
> + */
> + if (WARN_ON(group->domain == new_domain)) {
> + ret = -EINVAL;
> + goto err_unlock;
> + }
> +
> entry = iommu_make_pasid_array_entry(new_domain, handle);
> /*
> * iommu_attach_handle_get() runs without the group mutex, so unpublish
I am fine with this change.
Thanks,
baolu
next prev parent reply other threads:[~2026-11-02 6:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 21:51 [PATCH v1 0/4] iommu: Fix attach handle publication ordering Nicolin Chen
2026-09-29 21:51 ` [PATCH v1 1/4] iommu: Unpublish the attach handle before the group detach callback Nicolin Chen
2026-10-29 7:18 ` Tian, Kevin
2026-11-01 2:01 ` Baolu Lu
2026-09-29 21:51 ` [PATCH v1 2/4] iommu: Unpublish the attach handle before the PASID " Nicolin Chen
2026-10-29 7:18 ` Tian, Kevin
2026-11-01 2:13 ` Baolu Lu
2026-09-29 21:51 ` [PATCH v1 3/4] iommu: Unpublish the old attach handle before the group replace callback Nicolin Chen
2026-10-29 7:25 ` Tian, Kevin
2026-10-29 11:00 ` Yi Liu
2026-10-29 18:45 ` Jason Gunthorpe
2026-10-30 8:03 ` Tian, Kevin
2026-10-30 8:22 ` Yi Liu
2026-10-30 15:21 ` Jason Gunthorpe
2026-11-01 5:53 ` Baolu Lu
2026-11-02 3:30 ` Yi Liu
2026-11-02 5:54 ` Nicolin Chen
2026-11-02 6:05 ` Baolu Lu [this message]
2026-09-29 21:51 ` [PATCH v1 4/4] iommu: Unpublish the old attach handle before the PASID " Nicolin Chen
2026-10-29 7:26 ` Tian, Kevin
2026-11-01 5:54 ` Baolu Lu
2026-10-28 18:58 ` [PATCH v1 0/4] iommu: Fix attach handle publication ordering Nicolin Chen
2026-10-29 11:00 ` Yi Liu
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=e6624f1a-b6dd-4229-a26c-4b0501357b75@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=jpb@kernel.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®