Re: [PATCH v11 11/16] iommu/arm-smmu-v3: Add CMDQ_PROD_STOP_FLAG to gate CMDQ submissions

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] iommu/arm-smmu-v3: memory corruption from dropped ATC_INV when SMMU is suspended
--

commit 1d62496e7c0326798403d88bba79adbf58c43810
Author: Pranjal Shrivastava <praan@google.com>

iommu/arm-smmu-v3: Add CMDQ_PROD_STOP_FLAG to gate CMDQ submissions

This commit introduces a CMDQ_PROD_STOP_FLAG to safely gate command queue
submissions during device suspension. It checks this flag in the cmpxchg
loop to avoid abandoning batches and indefinite polling during drains.

> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
[ ... ]
> @@ -726,13 +727,42 @@ int __arm_smmu_cmdq_issue_cmdlist(struct arm_smmu_device *smmu,
>  	do {
>  		u64 old;
>  
> +		/*
> +		 * If the SMMU is suspended/suspending, any new CMDs are elided.
> +		 * This loop is the Point of Commitment. If we haven't cmpxchg'd
> +		 * our new indices yet, we can safely bail. Once the indices are
> +		 * committed, we MUST write valid commands to those slots to
> +		 * avoid indefinite polling in the drain function.
> +		 */
> +		if (Q_STOP(llq.prod)) {
> +			local_irq_restore(flags);
> +			return 0;
> +		}

[Severity: High]
Can this early return cause memory corruption by silently dropping ATC
invalidations?

When the SMMU suspends, Q_STOP(llq.prod) becomes true. If a driver or
background thread then calls dma_unmap() to free a buffer while a PCIe
endpoint (with ATS enabled) is suspended to a state like D0, the SMMU
driver will observe the stop flag here in __arm_smmu_cmdq_issue_cmdlist().

By bailing out and returning 0 (success) without actually submitting the
CMDQ_OP_ATC_INV command to the hardware, the IOMMU core is misled into
freeing the memory while the PCIe endpoint's Address Translation Cache
(ATC) retains the stale translation. When the PCI device resumes, or if
it issues a TLP while in D0, it could use the stale ATC entry to access
the now-freed memory, bypassing IOMMU protections.

Are we assuming endpoint drivers clear their own ATC or that a hardware
reset handles it? Client endpoint drivers typically lack an API to
manually clear the ATC, and SMMU hardware resets do not broadcast ATC
invalidations to endpoints.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929034510.2023173-1-praan@google.com?part=11