Re: [PATCH 1/6] arm64: dts: qcom: glymur: Add CAMSS and CSIPHY nodes for Glymur

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Out-Of-Bounds array access in the CAMSS driver due to using port@3 for csiphy4
--

commit b61951f794c7b5b6c37a3dd0050221dc787080bb
Author: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>

arm64: dts: qcom: glymur: Add CAMSS and CSIPHY nodes for Glymur
    
Glymur shares the same IP as X1E80100, with three CSIPHYs that use
the new standalone PHY API. Compared to X1E80100, csiphy2 is absent
on Glymur.

> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index 624a9edd602cf..c463cde46cc41 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
[ ... ]
> @@ -1842,6 +1886,285 @@ &config_noc SLAVE_QUP_1 QCOM_ICC_TAG_ALWAYS>,
>  			};
>  		};
>  
> +		camss: isp@acb6000 {
> +			compatible = "qcom,glymur-camss";
[ ... ]
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				port@0 {
> +					reg = <0>;
> +
> +					camss_csiphy0_inep: endpoint {
> +						remote-endpoint = <&csiphy0_out_ep>;
> +					};
> +				};
> +
> +				port@1 {
> +					reg = <1>;
> +
> +					camss_csiphy1_inep: endpoint {
> +						remote-endpoint = <&csiphy1_out_ep>;
> +					};
> +				};
> +
> +				port@3 {
> +					reg = <3>;
> +
> +					camss_csiphy4_inep: endpoint {
> +						remote-endpoint = <&csiphy4_out_ep>;
> +					};
> +				};

[Severity: High]
Will using port@3 here cause an out-of-bounds array access in the CAMSS
driver?

The CAMSS driver parses the device tree endpoint port number and assigns it
directly to csd->interface.csiphy_id in camss_parse_endpoint_node().

During async subdev binding in camss_subdev_notifier_bound(), this csiphy_id
is used directly as an array index (&camss->csiphy[id]) without bounds
checking.

Because Glymur has only three CSIPHYs (csiphy2 is absent), the future driver
resource definition will densely allocate camss->csiphy with exactly 3
elements (valid indices 0, 1, 2). Processing port@3 will therefore access
index 3, which is out-of-bounds and could lead to memory corruption or a
kernel panic during device probe.

Should this use port@2 instead (mapping to the flat array index 2), unless
the CAMSS driver is first refactored to decouple DT port indices from
physical array allocations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907-glymur_camss_dts-v1-0-6c2ced5ea5f9@oss.qualcomm.com?part=1