On 2020-12-15 04:15, tangzhenhao wrote:
From: Sugar <[email protected]>
we should check the ret-val of function rk_iommu_from_dev to avoid
null-ptr-deref.
Signed-off-by: Sugar <[email protected]>
---
drivers/iommu/rockchip-iommu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index e5d86b7177de..311d9eec06f4 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1064,6 +1064,9 @@ static struct iommu_device *rk_iommu_probe_device(struct
device *dev)
return ERR_PTR(-ENODEV);
iommu = rk_iommu_from_dev(dev);
+ if (!iommu) {
+ return ERR_PTR(-ENODEV);
+ }
Under what circumstances can data be valid but data->iommu be NULL? Note
that if data (i.e. iommu->priv) itself was NULL we couldn't have reached
this point.
data->link = device_link_add(dev, iommu->dev,
DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
@@ -1083,6 +1086,9 @@ static struct iommu_group *rk_iommu_device_group(struct
device *dev)
struct rk_iommu *iommu;
iommu = rk_iommu_from_dev(dev);
+ if (!iommu) {
+ return ERR_PTR(-ENODEV);
+ }
How can this possibly be NULL if rk_iommu_probe_device() succeeded such
that iommu_group_get_for_dev() could be called in the first place?
return iommu_group_ref_get(iommu->group);
}
If you've actually hit a bug in practice, please include a bit more
detail in the commit message so that everyone can understand the
circumstances of the crash better. If on the other hand you're only
trying to find theoretical bugs by code inspection, please try to
understand the code *in context*. Adding checks for conditions that can
only happen due to random memory corruption is not worthwhile.
Thanks,
Robin.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
