linux-kernel - Re: [PATCH 5/9] media: jpu: Do not zero reserved fields

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <63e16013-43f7-0ad5-76d1-a4d10c666382@xs4all.nl>
Date:   Thu, 21 Jan 2021 10:53:39 +0100
From:   Hans Verkuil <hverkuil@...all.nl>
To:     kieran.bingham+renesas@...asonboard.com,
        Ricardo Ribalda <ribalda@...omium.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Mikhail Ulyanov <mikhail.ulyanov@...entembedded.com>
Subject: Re: [PATCH 5/9] media: jpu: Do not zero reserved fields

On 12/01/2021 12:07, Kieran Bingham wrote:
> Hi Ricardo,
> 
> On 11/01/2021 14:54, Ricardo Ribalda wrote:
>> Core code already clears reserved fields of struct
>> v4l2_pix_format_mplane, check: 4e1e0eb0e074 ("media: v4l2-ioctl: Zero
>> v4l2_plane_pix_format reserved fields").
>>
>> Cc: Mikhail Ulyanov <mikhail.ulyanov@...entembedded.com>
>> Signed-off-by: Ricardo Ribalda <ribalda@...omium.org>
>> ---
>>  drivers/media/platform/rcar_jpu.c | 5 -----
>>  1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/media/platform/rcar_jpu.c b/drivers/media/platform/rcar_jpu.c
>> index 9b99ff368698..2bddc957cb87 100644
>> --- a/drivers/media/platform/rcar_jpu.c
>> +++ b/drivers/media/platform/rcar_jpu.c
> 
> There's a memset(cap->reserved...) in jpu_querycap()
> 
> Is that also applicable and covered by the core?

Yes: VIDIOC_QUERYCAP is a read-only ioctl: the core will always zero
the struct in that case before handing it over to the driver.

This is something for a separate patch, though. There may well be
more drivers that do this for querycap.

Regards,

	Hans

> 
> Looking at v4l_querycap() it doesn't seem to be so:
> 
> 
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@...asonboard.com>
> 
>> @@ -793,7 +793,6 @@ static int __jpu_try_fmt(struct jpu_ctx *ctx, struct jpu_fmt **fmtinfo,
>>  	pix->colorspace = fmt->colorspace;
>>  	pix->field = V4L2_FIELD_NONE;
>>  	pix->num_planes = fmt->num_planes;
>> -	memset(pix->reserved, 0, sizeof(pix->reserved));
>>  
>>  	jpu_bound_align_image(&pix->width, JPU_WIDTH_MIN, JPU_WIDTH_MAX,
>>  			      fmt->h_align, &pix->height, JPU_HEIGHT_MIN,
>> @@ -808,8 +807,6 @@ static int __jpu_try_fmt(struct jpu_ctx *ctx, struct jpu_fmt **fmtinfo,
>>  			pix->plane_fmt[0].sizeimage = JPU_JPEG_HDR_SIZE +
>>  				(JPU_JPEG_MAX_BYTES_PER_PIXEL * w * h);
>>  		pix->plane_fmt[0].bytesperline = 0;
>> -		memset(pix->plane_fmt[0].reserved, 0,
>> -		       sizeof(pix->plane_fmt[0].reserved));
>>  	} else {
>>  		unsigned int i, bpl = 0;
>>  
>> @@ -822,8 +819,6 @@ static int __jpu_try_fmt(struct jpu_ctx *ctx, struct jpu_fmt **fmtinfo,
>>  		for (i = 0; i < pix->num_planes; ++i) {
>>  			pix->plane_fmt[i].bytesperline = bpl;
>>  			pix->plane_fmt[i].sizeimage = bpl * h * fmt->bpp[i] / 8;
>> -			memset(pix->plane_fmt[i].reserved, 0,
>> -			       sizeof(pix->plane_fmt[i].reserved));
>>  		}
>>  	}
>>  
>>
>