Re: [PATCH v7 04/14] media: mediatek: vcodec: get different firmware ipi id

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: mtk-vcodec: out-of-bounds array write via unchecked firmware ipi id
--

commit 576e89832edf2cee2354139a5fddaa192a84287b
Author: Kyrie Wu <kyrie.wu@mediatek.com>

media: mediatek: vcodec: get different firmware ipi id
    
This commit introduces mtk_vcodec_fw_get_ipi() to fetch inter-processor
interrupt IDs based on firmware type and hardware index. It also updates
various slice initialization functions to use this new helper.

> diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
> index 552d0d8a84444..8630e871d78e2 100644
> --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
> +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
> @@ -3,6 +3,20 @@
>  #include "../decoder/mtk_vcodec_dec_drv.h"
>  #include "../encoder/mtk_vcodec_enc_drv.h"
>  #include "mtk_vcodec_fw_priv.h"
> +#include "mtk_vcodec_fw_vcp.h"
> +
> +int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int hw_id)
> +{
> +	switch (type) {
> +	case SCP:
> +		return hw_id == MTK_VDEC_LAT0 ? SCP_IPI_VDEC_LAT : SCP_IPI_VDEC_CORE;
> +	case VCP:
> +		return hw_id == MTK_VDEC_LAT0 ? VCP_IPI_LAT_DECODER : VCP_IPI_CORE_DECODER;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_ipi);

[ ... ]

> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
> index 2d622e85f8271..756fbb7778b1f 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c
> @@ -1877,6 +1877,7 @@ static int vdec_av1_slice_init(struct mtk_vcodec_dec_ctx *ctx)
>  {
>  	struct vdec_av1_slice_instance *instance;
>  	struct vdec_av1_slice_init_vsi *vsi;
> +	enum mtk_vcodec_fw_type fw_type = ctx->dev->fw_handler->type;
>  	int ret;
>  
>  	instance = kzalloc_obj(*instance);
> @@ -1884,8 +1885,8 @@ static int vdec_av1_slice_init(struct mtk_vcodec_dec_ctx *ctx)
>  		return -ENOMEM;
>  
>  	instance->ctx = ctx;
> -	instance->vpu.id = SCP_IPI_VDEC_LAT;
> -	instance->vpu.core_id = SCP_IPI_VDEC_CORE;
> +	instance->vpu.id = mtk_vcodec_fw_get_ipi(fw_type, MTK_VDEC_LAT0);
> +	instance->vpu.core_id = mtk_vcodec_fw_get_ipi(fw_type, MTK_VDEC_CORE);

[Severity: High]
If fw_type is unsupported like VPU, mtk_vcodec_fw_get_ipi() will return
-EINVAL. Does assigning this negative error code directly to vpu.id without
validation cause an out-of-bounds write later?

When vpu_dec_init() calls mtk_vcodec_fw_ipi_register(), it routes to
vpu_ipi_register(). The bounds check in vpu_ipi_register() only verifies
that the ID is less than IPI_MAX, but lacks a lower bound check:

drivers/media/platform/mediatek/vpu/mtk_vpu.c:vpu_ipi_register() {
	...
	if (id < IPI_MAX && handler) {
		ipi_desc = vpu->ipi_desc;
		ipi_desc[id].name = name;
	...
}

Could this allow the negative ID to bypass the bounds check and perform
an out-of-bounds write to the ipi_desc array? This same pattern appears
in the other slice initialization functions updated in this patch.

>  	instance->vpu.ctx = ctx;
>  	instance->vpu.codec_type = ctx->current_codec;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923024258.257846-1-kyrie.wu@mediatek.com?part=4