Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org,
	media-ci@linuxtv.org, neil.armstrong@linaro.org,
	vkoul@kernel.org, olteanv@gmail.com, robh@kernel.org,
	linux-phy@lists.infradead.org
Subject: Re: [PATCH v19 05/12] media: qcom: camss: Add Kaanapali compatible
Date: Thu, 08 Oct 2026 07:29:19 +0000	[thread overview]
Message-ID: <sashiko-outbox-163759@kernel.org> (raw)
In-Reply-To: <20261008-kaanapali-camss-v19-5-b2c583ef50e0@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: qcom: camss: missing DT port bounds check in camss_parse_endpoint_node()
--

commit 781d7cc1d1be2a0b64ef04982c38bd82fc6c1a5d
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>

    media: qcom: camss: Add Kaanapali compatible
    
    Add CAMSS_KAANAPALI enum, Kaanapali compatible and Kaanapali CAMSS driver
    private data. The private data currently includes only basic information.
    Later changes will add CSIPHY, TPG, CSID and VFE resources.

> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index c54185c93a8a9..fca3de214a922 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c

[ ... ]

> @@ -5576,6 +5590,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),
> +};
> +

[Severity: High]
Does this code allow an out-of-bounds array access if a malformed device tree
provides an excessively large port number?

The driver parses the port endpoint from the device tree in
camss_parse_endpoint_node() and stores it without bounds checking:

drivers/media/platform/qcom/camss/camss.c:camss_parse_endpoint_node() {
	...
	csd->interface.csiphy_id = vep.base.port;
	...
}

Then in camss_subdev_notifier_bound(), this unvalidated id is used to index
into the dynamically allocated camss->csiphy array:

drivers/media/platform/qcom/camss/camss.c:camss_subdev_notifier_bound() {
	...
	u8 id = csd->interface.csiphy_id;
	struct csiphy_device *csiphy = &camss->csiphy[id];
	...
}

Could this lead to memory corruption or a kernel panic if the port number
exceeds camss->res->csiphy_num?

While the specific zero-size pointer issue for Kaanapali is resolved by
follow-up patches setting csiphy_num, the missing bounds validation appears to
remain a vulnerability for any invalid device tree.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-kaanapali-camss-v19-0-b2c583ef50e0@oss.qualcomm.com?part=5

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-10-08  7:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  7:14 [PATCH v19 00/12] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-10-08  7:14 ` [PATCH v19 01/12] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-10-08  7:14 ` [PATCH v19 02/12] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-10-08 22:08   ` bod
2026-10-08  7:14 ` [PATCH v19 03/12] phy: qcom-mipi-csi2: Add Kaanapali support Hangxiang Ma
2026-10-08 22:32   ` bod
2026-10-08  7:14 ` [PATCH v19 04/12] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-10-08  7:14 ` [PATCH v19 05/12] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-10-08  7:29   ` sashiko-bot [this message]
2026-10-08  7:14 ` [PATCH v19 06/12] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2026-10-08  7:30   ` sashiko-bot
2026-10-08 22:38   ` bod
2026-10-08  7:14 ` [PATCH v19 07/12] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2026-10-08  7:32   ` sashiko-bot
2026-10-08  7:14 ` [PATCH v19 08/12] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
2026-10-08  7:33   ` sashiko-bot
2026-10-08 22:50   ` bod
2026-10-09  2:59     ` Hangxiang Ma
2026-10-09  8:39       ` Bryan O'Donoghue
2026-10-09 11:36         ` Hangxiang Ma
2026-10-08  7:14 ` [PATCH v19 09/12] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-10-08  7:27   ` sashiko-bot
2026-10-08  7:14 ` [PATCH v19 10/12] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-10-08  7:38   ` sashiko-bot
2026-10-09  8:40   ` Bryan O'Donoghue
2026-10-09  8:45     ` hangxiang.ma
2026-10-08  7:14 ` [PATCH v19 11/12] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-10-08 16:16   ` Loic Poulain
2026-10-09  4:06     ` Hangxiang Ma
2026-10-08  7:14 ` [PATCH v19 12/12] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-163759@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hangxiang.ma@oss.qualcomm.com \
    --cc=linux-phy@lists.infradead.org \
    --cc=media-ci@linuxtv.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox