[PATCH] iommu/arm-smmu-v3: Skip unlinked duplicate stream nodes on removal

[PATCH] iommu/arm-smmu-v3: Skip unlinked duplicate stream nodes on removal

[zhoumin]

A master's firmware stream ID list can contain duplicates, for example
for PCI devices behind an aliasing bridge. arm_smmu_insert_master()
accepts these IDs when the existing stream belongs to the same master,
but does not link the duplicate stream's rb_node into the SID tree.

Both arm_smmu_remove_master() and the insertion error path nevertheless
call rb_erase() for every stream in their respective ranges. Erasing a
zero-initialized, unlinked node can clear the tree root, losing SID to
master mappings for other devices sharing the SMMU and leaving the tree
inconsistent for subsequent operations.

Mark skipped duplicate nodes with RB_CLEAR_NODE() and skip them in both
removal paths. Set the marker after sorting the stream array, since it
contains the node's own address. Keep the stream array and num_streams
unchanged to preserve existing STE, invalidation and single-stream
feature checks.

Fixes: b00d24997a11 ("iommu/arm-smmu-v3: Fix iommu_device_probe bug due to duplicated stream ids")
Cc: stable@vger.kernel.org
Signed-off-by: zhoumin <teczm@foxmail.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

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 5732f3ba0122..2627d496921e 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4141,8 +4141,10 @@ static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
 					->master;
 
 			/* Bridged PCI devices may end up with duplicated IDs */
-			if (existing_master == master)
+			if (existing_master == master) {
+				RB_CLEAR_NODE(&new_stream->node);
 				continue;
+			}
 
 			dev_warn(master->dev,
 				 "Aliasing StreamID 0x%x (from %s) unsupported, expect DMA to be broken\n",
@@ -4154,7 +4156,8 @@ static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
 
 	if (ret) {
 		for (i--; i >= 0; i--)
-			rb_erase(&master->streams[i].node, &smmu->streams);
+			if (!RB_EMPTY_NODE(&master->streams[i].node))
+				rb_erase(&master->streams[i].node, &smmu->streams);
 		kfree(master->streams);
 		kfree(master->build_invs);
 	}
@@ -4174,7 +4177,8 @@ static void arm_smmu_remove_master(struct arm_smmu_master *master)
 
 	mutex_lock(&smmu->streams_mutex);
 	for (i = 0; i < fwspec->num_ids; i++)
-		rb_erase(&master->streams[i].node, &smmu->streams);
+		if (!RB_EMPTY_NODE(&master->streams[i].node))
+			rb_erase(&master->streams[i].node, &smmu->streams);
 	mutex_unlock(&smmu->streams_mutex);
 
 	kfree(master->streams);
-- 
2.53.0

Re: [PATCH] iommu/arm-smmu-v3: Skip unlinked duplicate stream nodes on removal

[Nicolin Chen]

On Mon, Sep 21, 2026 at 08:17:27PM +0800, zhoumin wrote:
> A master's firmware stream ID list can contain duplicates, for example
> for PCI devices behind an aliasing bridge. arm_smmu_insert_master()
> accepts these IDs when the existing stream belongs to the same master,
> but does not link the duplicate stream's rb_node into the SID tree.
> 
> Both arm_smmu_remove_master() and the insertion error path nevertheless
> call rb_erase() for every stream in their respective ranges. Erasing a
> zero-initialized, unlinked node can clear the tree root, losing SID to
> master mappings for other devices sharing the SMMU and leaving the tree
> inconsistent for subsequent operations.
> 
> Mark skipped duplicate nodes with RB_CLEAR_NODE() and skip them in both
> removal paths. Set the marker after sorting the stream array, since it
> contains the node's own address. Keep the stream array and num_streams
> unchanged to preserve existing STE, invalidation and single-stream
> feature checks.
> 
> Fixes: b00d24997a11 ("iommu/arm-smmu-v3: Fix iommu_device_probe bug due to duplicated stream ids") 

I submitted a similar fix a while ago:
https://lore.kernel.org/linux-iommu/9136477b9c737a50cecc38f2ee6704a01510169a.1783044582.git.nicolinc@nvidia.com/

I wonder if you really hit the issue or it's just a Sashiko finding?

Nicolin