On 16.07.2019, at 00:50, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> Fixes: division by 0 > Fixes: > 15657/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5738154838982656 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > --- > libavcodec/fitsdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/fitsdec.c b/libavcodec/fitsdec.c > index 4f452422ef..fe941f199d 100644 > --- a/libavcodec/fitsdec.c > +++ b/libavcodec/fitsdec.c > @@ -174,7 +174,7 @@ static int fits_read_header(AVCodecContext *avctx, const > uint8_t **ptr, FITSHead > return AVERROR_INVALIDDATA; > } > av_log(avctx, AV_LOG_WARNING, "data min/max indicates a blank > image\n"); > - header->data_max ++; > + header->data_max += fabs(header->data_max) / 10000000 + 1; This is really non-obvious, both by itself, in where/how it causes the division by 0 and that the error here isn't worse than the division by 0 for example, and why this constant was chosen. Also why a division and not a multiply by the inverse? Why not * (1.0f / (1 << 24)) for example, which for single-precision IEEE I think should result in exactly 1 ULP (well, possibly 2 with rounding) increments? Why is this even using floating-point? And why not double-precision at least? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
