Re: [PATCH v3 04/13] iommu/arm-smmu-v3: Flush in-flight fault work on domain detach

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Pre-existing UAF on the IOMMU core domain during a race window between IOPF queue flush and IOMMU core handle update.
--

commit fe39d3d0018e082fcdaca3fbd4d2a4bd526c0f92
Author: Nicolin Chen <nicolinc@nvidia.com>

    iommu/arm-smmu-v3: Flush in-flight fault work on domain detach

This commit adds synchronization and flushing of the IOPF queue during domain
detach. It ensures that all in-flight stall events and fault work are handled
or safely leaked in case of timeouts.

> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index d255ff2519f9d..1851ee7ec15b9 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3412,8 +3413,40 @@ void arm_smmu_attach_release(struct arm_smmu_attach_state *state)
[ ... ]
> +	/*
> +	 * Only IOPF-enabled attachments queue fault work, and such work
> +	 * references the old domain via its attach handle. Flush it, as
> +	 * the IOMMU core might free the old domain once this returns.
> +	 */
> +	if (master_domain->using_iopf) {
> +		/* Lastly, drain the IOPF queue */
> +		iopf_queue_flush_dev(master->dev);

[Severity: Critical]
This is a pre-existing issue, but does flushing the IOPF queue here leave a
race window open for new faults to be resolved to the old domain before the
function returns and the IOMMU core updates the attach handle?

During a domain transition, the hardware is reconfigured to the new domain,
and arm_smmu_attach_release() calls iopf_queue_flush_dev(). If the device
immediately generates a new fault, the EVTQ IRQ thread reads it and calls
iommu_report_device_fault().

Because the IOMMU core only updates the attach handle after the driver's
operation returns, the new fault is incorrectly resolved to the old domain's
handle and queued as fault work.

The IOMMU core then frees the old domain, and the queued work executes,
dereferencing the freed domain via
group->attach_handle->domain->iopf_handler(group).

Can this result in a Use-After-Free of the iommu_domain structure by an
untrusted guest or device generating faults immediately after a domain
transition?

> +
> +		/*
> +		 * A timed-out drain may leave fault work in flight, and
> +		 * iopf_queue_remove_device() would free iopf groups that
> +		 * such work still references. Skip the iopf teardown and
> +		 * leak master_domain, rather than risk a UAF.
> +		 */
> +		if (WARN_ON(ret)) {
> +			state->old_master_domain = NULL;
> +			return;
> +		}
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788222485.git.nicolinc@nvidia.com?part=4