[PATCH v20 06/13] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: qcom: camss: NULL deref in msm_csiphy_subdev_init_legacy() on malformed DT
--

commit 08f91d74b650b5a3e039a9cddfa9acbe4783d78b
Author: Hangxiang Ma <hangxiang.ma at oss.qualcomm.com>

media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY

Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
rather than by CAMSS.

> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index fca3de214a922..eeceb79c1e863 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -38,6 +38,51 @@
>  
>  static const struct parent_dev_ops vfe_parent_dev_ops;
>  
> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
> +	/* CSIPHY0 */
> +	{
> +		.csiphy = {
> +			.id = 0,
> +			.formats = &csiphy_formats_sdm845
> +		},
> +	},

[Severity: High]
Does this configuration cause a NULL pointer dereference if the Device Tree
is malformed?

Since .hw_ops is intentionally omitted for this configuration, it expects to
use the standalone driver. However, if the Device Tree is malformed and lacks
endpoints (for example, if an overlay is missing or incorrectly configured),
camss_detect_legacy_phy() does not execute its loop and legacy_phy remains
true:

drivers/media/platform/qcom/camss/camss.c:camss_detect_legacy_phy() {
    ...
    camss->legacy_phy = true;

    /* Find first remote-endpoint and determine if its a PHY */
    for_each_endpoint_of_node(camss->dev->of_node, ep) {
    ...
}

This true value forces the probe to take the fallback legacy path and call
msm_csiphy_subdev_init_legacy(), which unconditionally dereferences
hw_ops->init:

drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init_legacy() {
    ...
    csiphy->res = &res->csiphy;

    ret = csiphy->res->hw_ops->init(csiphy);
    ...
}

Should untrusted or malformed configurations be handled without panicking the
kernel?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010-kaanapali-camss-v20-0-63e98ce9ac0c@oss.qualcomm.com?part=6