Re: [PATCH v13 2/5] media: qcom: camss: Add Kaanapali compatible camss driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Out-of-bounds memory write and kernel panic due to missing bounds check on devicetree endpoint port ID.
- [Low] DT compatible string uses an internal codename ('kaanapali') instead of a formal SoC part number.
--

commit 4432b1ccccdf08cae8c8cb1876abd2d97b1956f7
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>

media: qcom: camss: Add Kaanapali compatible camss driver

This commit adds support for the Kaanapali platform to the camss driver. It
introduces high-level resource information, bus bandwidth votes, and a
matching devicetree compatible string.

> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 9335636d7c4df..ffaeeb9d17976 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -5102,6 +5116,13 @@ static void camss_remove(struct platform_device *pdev)
>  	camss_genpd_cleanup(camss);
>  }
>  
> +static const struct camss_resources kaanapali_resources = {
> +	.version = CAMSS_KAANAPALI,
> +	.pd_name = "top",
> +	.icc_res = icc_res_kaanapali,
> +	.icc_path_num = ARRAY_SIZE(icc_res_kaanapali),
> +};

Does this incomplete resource structure introduce a panic during setup?

Because csiphy_num is implicitly 0 here, devm_kcalloc allocates a 0-sized
array and returns ZERO_SIZE_PTR for the csiphy array.

If a devicetree contains endpoints, camss_parse_endpoint_node() directly
assigns the port number from the devicetree endpoint to
csd->interface.csiphy_id without verifying it is within the bounds of
camss->res->csiphy_num.

When an external sensor binds, camss_subdev_notifier_bound() then blindly
uses this ID to index &camss->csiphy[id]. Because it offsets from
ZERO_SIZE_PTR and writes to csiphy->cfg.csi2, this causes an immediate
kernel panic.

While a later commit in the series (media: qcom: camss: csiphy: Add support
for v2.4.0 two-phase CSIPHY, sha: de1603c8ca2ad) populates csiphy_res and
resolves the 0-sized array issue, the underlying missing bounds check
remains. A devicetree specifying a port ID greater than or equal to
csiphy_num will still trigger an out-of-bounds write.

Could we add a bounds check against camss->res->csiphy_num when parsing the
endpoint node?

> +
>  static const struct camss_resources msm8916_resources = {
>  	.version = CAMSS_8x16,
>  	.csiphy_res = csiphy_res_8x16,
[ ... ]
> @@ -5316,6 +5337,7 @@ static const struct camss_resources x1e80100_resources = {
>  };
>  
>  static const struct of_device_id camss_dt_match[] = {
> +	{ .compatible = "qcom,kaanapali-camss", .data = &kaanapali_resources },

This isn't a bug, but upstream devicetree naming conventions require the use
of official, public SoC part numbers (like sm8550 or x1e80100) rather than
internal manufacturer codenames.

Is it possible to update qcom,kaanapali-camss to use the actual Snapdragon
SoC model number it represents, to stay consistent with the rest of the
matching table?

>  	{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
>  	{ .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
>  	{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260508-kaanapali-camss-v13-0-2541d8e55651@oss.qualcomm.com?part=2