All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
	neil.armstrong@linaro.org, vkoul@kernel.org,
	media-ci@linuxtv.org, olteanv@gmail.com,
	linux-phy@lists.infradead.org
Subject: Re: [PATCH v18 07/11] media: qcom: camss: vfe: Add support for VFE 1080
Date: Sat, 03 Oct 2026 09:21:29 +0000	[thread overview]
Message-ID: <20261003092130.7930D1F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261003-kaanapali-camss-v18-7-87ba4ebe0db1@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] camss: out-of-bounds DMA due to AUP_UPDATE mismatch
--

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

media: qcom: camss: vfe: Add support for VFE 1080

This commit adds support for the Video Front End (VFE) 1080 module found on
the Kaanapali SoC.

> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 2680a9914765f..3acef6ba97dc9 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
>  		output->gen2.active_num++;
>  		ops->vfe_wm_update(vfe, output->wm_idx[0],
>  				   output->buf[i]->addr[0], line);
> -		ops->reg_update(vfe, line->id);
> +
> +		if (!vfe->res->reg_update_after_csid_config)
> +			ops->reg_update(vfe, line->id);
>  	}

[Severity: High]
Does this code handle the case where userspace queues fewer than 2 buffers?

If fewer than 2 buffers are queued, the loop above breaks early when 
vfe_buf_get_pending() returns NULL, leaving active_num < 2 without returning 
an error.

The commit message notes that "the number of AUP_UPDATE requests must match 
the number of buffers queued to the write master while it is being enabled."

However, if we proceed with active_num < 2, the pipeline start continues, and 
csid_configure_stream() in camss-csid-1080.c will unconditionally issue 
CAMSS_INIT_BUF_COUNT (2) AUP updates:

drivers/media/platform/qcom/camss/camss-csid-1080.c:csid_configure_stream() {
	...
	for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
		__csid_aup_update(csid, i);
	...
}

Could this mismatch between AUP updates and actually queued buffers lead to 
the VFE write master hardware attempting out-of-bounds DMA to uninitialized 
addresses and causing memory corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com?part=7

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

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
	neil.armstrong@linaro.org, vkoul@kernel.org,
	media-ci@linuxtv.org, olteanv@gmail.com,
	linux-phy@lists.infradead.org
Subject: Re: [PATCH v18 07/11] media: qcom: camss: vfe: Add support for VFE 1080
Date: Sat, 03 Oct 2026 09:21:29 +0000	[thread overview]
Message-ID: <20261003092130.7930D1F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261003-kaanapali-camss-v18-7-87ba4ebe0db1@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] camss: out-of-bounds DMA due to AUP_UPDATE mismatch
--

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

media: qcom: camss: vfe: Add support for VFE 1080

This commit adds support for the Video Front End (VFE) 1080 module found on
the Kaanapali SoC.

> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 2680a9914765f..3acef6ba97dc9 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
>  		output->gen2.active_num++;
>  		ops->vfe_wm_update(vfe, output->wm_idx[0],
>  				   output->buf[i]->addr[0], line);
> -		ops->reg_update(vfe, line->id);
> +
> +		if (!vfe->res->reg_update_after_csid_config)
> +			ops->reg_update(vfe, line->id);
>  	}

[Severity: High]
Does this code handle the case where userspace queues fewer than 2 buffers?

If fewer than 2 buffers are queued, the loop above breaks early when 
vfe_buf_get_pending() returns NULL, leaving active_num < 2 without returning 
an error.

The commit message notes that "the number of AUP_UPDATE requests must match 
the number of buffers queued to the write master while it is being enabled."

However, if we proceed with active_num < 2, the pipeline start continues, and 
csid_configure_stream() in camss-csid-1080.c will unconditionally issue 
CAMSS_INIT_BUF_COUNT (2) AUP updates:

drivers/media/platform/qcom/camss/camss-csid-1080.c:csid_configure_stream() {
	...
	for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
		__csid_aup_update(csid, i);
	...
}

Could this mismatch between AUP updates and actually queued buffers lead to 
the VFE write master hardware attempting out-of-bounds DMA to uninitialized 
addresses and causing memory corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003-kaanapali-camss-v18-0-87ba4ebe0db1@oss.qualcomm.com?part=7

  reply	other threads:[~2026-10-03  9:21 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-03  9:02 [PATCH v18 00/11] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-10-03  9:02 ` Hangxiang Ma
2026-10-03  9:02 ` [PATCH v18 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:02 ` [PATCH v18 02/11] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:04   ` Bryan O'Donoghue
2026-10-03  9:04     ` Bryan O'Donoghue
2026-10-06  2:56   ` Rob Herring (Arm)
2026-10-06  2:56     ` Rob Herring (Arm)
2026-10-03  9:02 ` [PATCH v18 03/11] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:02 ` [PATCH v18 04/11] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:08   ` Bryan O'Donoghue
2026-10-03  9:08     ` Bryan O'Donoghue
2026-10-03 11:10     ` Hangxiang Ma
2026-10-03 11:10       ` Hangxiang Ma
2026-10-03 21:13       ` Bryan O'Donoghue
2026-10-03 21:13         ` Bryan O'Donoghue
2026-10-03  9:02 ` [PATCH v18 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:09   ` Bryan O'Donoghue
2026-10-03  9:09     ` Bryan O'Donoghue
2026-10-03 11:11     ` Hangxiang Ma
2026-10-03 11:11       ` Hangxiang Ma
2026-10-03  9:02 ` [PATCH v18 06/11] media: qcom: camss: csid: Add support for CSID 1080 Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:18   ` sashiko-bot
2026-10-03  9:18     ` sashiko-bot
2026-10-03  9:02 ` [PATCH v18 07/11] media: qcom: camss: vfe: Add support for VFE 1080 Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:21   ` sashiko-bot [this message]
2026-10-03  9:21     ` sashiko-bot
2026-10-03  9:02 ` [PATCH v18 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:16   ` sashiko-bot
2026-10-03  9:16     ` sashiko-bot
2026-10-03  9:02 ` [PATCH v18 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:19   ` sashiko-bot
2026-10-03  9:19     ` sashiko-bot
2026-10-03  9:02 ` [PATCH v18 10/11] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-10-03  9:02   ` Hangxiang Ma
2026-10-03  9:02 ` [PATCH v18 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma
2026-10-03  9:02   ` 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=20261003092130.7930D1F0089B@smtp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.