Re: [FFmpeg-devel] [PATCH 5/5] avformat/pcm: Use 64bit in bitrate computation

[Marton Balint <cus@passwd.hu>]

On Thu, 4 Apr 2024, Michael Niedermayer wrote:

> Fixes: signed integer overflow: 65792 * 65312 cannot be represented in type 'int'
> Fixes: 67819/clusterfuzz-testcase-minimized-ffmpeg_dem_WADY_fuzzer-5236100912185344
>
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
> libavformat/pcm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/pcm.c b/libavformat/pcm.c
> index 051e86dd464..a774dbc3726 100644
> --- a/libavformat/pcm.c
> +++ b/libavformat/pcm.c
> @@ -41,7 +41,7 @@ int ff_pcm_default_packet_size(AVCodecParameters *par)
>     /* Don't trust the codecpar bitrate if we can calculate it ourselves */
>     if (bits_per_sample > 0 && par->sample_rate > 0 && par->ch_layout.nb_channels > 0)
>         if ((int64_t)par->sample_rate * par->ch_layout.nb_channels < INT64_MAX / bits_per_sample)
> -            bitrate = bits_per_sample * par->sample_rate * par->ch_layout.nb_channels;
> +            bitrate = bits_per_sample * (int64_t)par->sample_rate * par->ch_layout.nb_channels;

LGTM, thanks.

I wonder why we usually cast the second operand and not the first to 64 
bit, since cast has higher precedence than multiplication, it should not 
matter, should it?

Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".