[PATCH] scsi: libsas: Fix potential array out of bounds in sas_check_*_expander_topo().

[PATCH] scsi: libsas: Fix potential array out of bounds in sas_check_*_expander_topo().

[Chaohai Chen]

No check was made to ensure that parent_phy->appended_phy_id is within the
valid range. If the expander reports an invalid phy_id, it may cause the
array to be out of bounds.

Signed-off-by: Chaohai Chen <wdhh6@aliyun.com>
---
 drivers/scsi/libsas/sas_expander.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
index d953225f6cc2..07633d795182 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1266,6 +1266,11 @@ static int sas_check_edge_expander_topo(struct domain_device *child,
 	struct expander_device *parent_ex = &child->parent->ex_dev;
 	struct ex_phy *child_phy;
 
+	if (parent_phy->attached_phy_id >= child_ex->num_phys) {
+		pr_err("Invalid attached_phy_id:%u, num_phys:%u\n",
+			parent_phy->attached_phy_id, child_ex->num_phys);
+		return -EINVAL;
+	}
 	child_phy = &child_ex->ex_phy[parent_phy->attached_phy_id];
 
 	if (child->dev_type == SAS_FANOUT_EXPANDER_DEVICE) {
@@ -1296,6 +1301,11 @@ static int sas_check_fanout_expander_topo(struct domain_device *child,
 	struct expander_device *child_ex = &child->ex_dev;
 	struct ex_phy *child_phy;
 
+	if (parent_phy->attached_phy_id >= child_ex->num_phys) {
+		pr_err("Invalid attached_phy_id:%u, num_phys:%u\n",
+			parent_phy->attached_phy_id, child_ex->num_phys);
+		return -EINVAL;
+	}
 	child_phy = &child_ex->ex_phy[parent_phy->attached_phy_id];
 
 	if (parent_phy->routing_attr == TABLE_ROUTING &&
-- 
2.43.7

Re: [PATCH] scsi: libsas: Fix potential array out of bounds in sas_check_*_expander_topo().

[James Bottomley]

On Mon, 2025-12-08 at 15:31 +0800, Chaohai Chen wrote:
> No check was made to ensure that parent_phy->appended_phy_id is
> within the valid range. If the expander reports an invalid phy_id, it
> may cause the array to be out of bounds.

We tend to assume hardware operates correctly unless there's a known
faulty device that we need to code around.  Have you got a device that
exhibits this problem?  Assuming you do, I think the fix is a little
harsh: wouldn't it be better to ignore the misnumbered phy than to
ignore the entire expander?

Regards,

James