Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5a70c141736e91f635f71d9922a3bbe993a76c69.camel@ndufresne.ca>
Subject: Re: [PATCH v2] media: vcodec: Fix potential array out-of-bounds in
 encoder queue_setup
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Wei Chen <harperchen1110@gmail.com>, tiffany.lin@mediatek.com
Cc:     andrew-ct.chen@mediatek.com, yunfei.dong@mediatek.com,
        mchehab@kernel.org, matthias.bgg@gmail.com,
        angelogioacchino.delregno@collabora.com,
        linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org, stable@vger.kernel.org
Date:   Thu, 10 Aug 2023 09:58:17 -0400
In-Reply-To: <20230810082333.972165-1-harperchen1110@gmail.com>
References: <20230810082333.972165-1-harperchen1110@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

Hi,

Le jeudi 10 ao=C3=BBt 2023 =C3=A0 08:23 +0000, Wei Chen a =C3=A9crit=C2=A0:
> variable *nplanes is provided by user via system call argument. The
> possible value of q_data->fmt->num_planes is 1-3, while the value
> of *nplanes can be 1-8. The array access by index i can cause array
> out-of-bounds.
>=20
> Fix this bug by checking *nplanes against the array size.
>=20
> Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video E=
ncoder Driver")
> Signed-off-by: Wei Chen <harperchen1110@gmail.com>
> Cc: stable@vger.kernel.org
> ---
> Changes in v2:
> - Add Fixes tag and CC stable email address
> - Change the title to be more expressive
>=20
>  drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c | 2 ++
>  1 file changed, 2 insertions(+)
>=20
> diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c b/dr=
ivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c
> index 9ff439a50f53..9e8817863cb8 100644
> --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_enc.c
> @@ -821,6 +821,8 @@ static int vb2ops_venc_queue_setup(struct vb2_queue *=
vq,
>  		return -EINVAL;
> =20
>  	if (*nplanes) {
> +		if (*nplanes !=3D q_data->fmt->num_planes)
> +			return -EINVAL;

I don't think the claim really exists. 	For this driver, when *nplane is se=
t,
it will be:


        case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
                requested_planes =3D f->fmt.pix_mp.num_planes;
                if (requested_planes =3D=3D 0 ||
                    requested_planes > VIDEO_MAX_PLANES)
                        return -EINVAL;
                for (i =3D 0; i < requested_planes; i++)
                        requested_sizes[i] =3D
                                f->fmt.pix_mp.plane_fmt[i].sizeimage;
                break;

Or the value the driver have set it in the previous call with *nplane =3D=
=3D 0. So
unless there is a bug, this should not happen, and more importantly, the co=
re
should not let that happen, meaning it should not be driver jobs to validat=
e
this.

my 2 cents,
Nicolas


>  		for (i =3D 0; i < *nplanes; i++)
>  			if (sizes[i] < q_data->sizeimage[i])
>  				return -EINVAL;