linux-kernel - Re: [PATCH] media: aspeed: Fix memory overwrite if timing is 1600x900

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 12 Jul 2023 12:09:15 +0200
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     Jammy Huang <jammy_huang@...eedtech.com>
Cc:     eajames@...ux.ibm.com, mchehab@...nel.org, joel@....id.au,
        andrew@...id.au, linux-media@...r.kernel.org,
        openbmc@...ts.ozlabs.org, linux-arm-kernel@...ts.infradead.org,
        linux-aspeed@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: aspeed: Fix memory overwrite if timing is 1600x900

Dear Jammy,


Thank you very much for your patch.

Am 12.07.23 um 11:26 schrieb Jammy Huang:
> When capturing 1600x900, system could crash when system memory usage is
> tight.

Please provide part of the trace, and if you have a commend to reproduce 
it, please also add it. Is it documented somewhere, that it needs to be 
aligned?

> The size of macro block captured is 8x8. Therefore, we should make sure
> the height of src-buf is 8 aligned to fix this issue.
> 
> Signed-off-by: Jammy Huang <jammy_huang@...eedtech.com>
> ---
>   drivers/media/platform/aspeed/aspeed-video.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/aspeed/aspeed-video.c b/drivers/media/platform/aspeed/aspeed-video.c
> index 374eb7781936..14594f55a77f 100644
> --- a/drivers/media/platform/aspeed/aspeed-video.c
> +++ b/drivers/media/platform/aspeed/aspeed-video.c
> @@ -1130,7 +1130,7 @@ static void aspeed_video_get_resolution(struct aspeed_video *video)
>   static void aspeed_video_set_resolution(struct aspeed_video *video)
>   {
>   	struct v4l2_bt_timings *act = &video->active_timings;
> -	unsigned int size = act->width * act->height;
> +	unsigned int size = act->width * ALIGN(act->height, 8);
>   
>   	/* Set capture/compression frame sizes */
>   	aspeed_video_calc_compressed_size(video, size);
> @@ -1147,7 +1147,7 @@ static void aspeed_video_set_resolution(struct aspeed_video *video)
>   		u32 width = ALIGN(act->width, 64);
>   
>   		aspeed_video_write(video, VE_CAP_WINDOW, width << 16 | act->height);
> -		size = width * act->height;
> +		size = width * ALIGN(act->height, 8);

Maybe add a comment.

Excuse my ignorance, but as `width` is already 64 bit aligned, how does 
aligning the second factor make a difference for `size`? Can you give an 
example?

>   	} else {
>   		aspeed_video_write(video, VE_CAP_WINDOW,
>   				   act->width << 16 | act->height);
> 
> base-commit: 2605e80d3438c77190f55b821c6575048c68268e


Kind regards,

Paul