[FFmpeg-devel] [PATCH] avcodec/jpeg2000dec: Ensure calculation of buf_size cannot overflow.

Michael Niedermayer michael at niedermayer.cc
Sat Apr 29 02:04:32 EEST 2023


On Fri, Apr 28, 2023 at 07:42:48AM +0300, etemesicaleb at gmail.com wrote:
> From: caleb <etemesicaleb at gmail.com>
> 
> ---
>  libavcodec/jpeg2000htdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> index 51cd96e0f1..d77293ddd8 100644
> --- a/libavcodec/jpeg2000htdec.c
> +++ b/libavcodec/jpeg2000htdec.c
> @@ -595,7 +595,7 @@ static int jpeg2000_decode_ht_cleanup_segment(const Jpeg2000DecoderContext *s,
>      const uint16_t quad_width  = ff_jpeg2000_ceildivpow2(width, 1);
>      const uint16_t quad_height = ff_jpeg2000_ceildivpow2(height, 1);
>  
> -    size_t buf_size = 4 * quad_width * quad_height;
> +    size_t buf_size = 4UL * quad_width * quad_height;

The only caller asserts that width and height are <= 1024 so this change
should not be needed
4 is an int and int is by POSIX 32bit at least

if you want to make the code "nicer", i would suggest
changing the quad_width and quad_height to int. uint16_t should generally
only be used if theres a reason. (space for an array can be a reason so can
it be to intentionally truncate to 16bit) But needing only 16bit is a bad
reason. uint16_t is generally not faster, in fact C treats it like a int anyway

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230429/df10ffec/attachment.sig>


More information about the ffmpeg-devel mailing list