[FFmpeg-devel] [PATCH 4/4] avcodec/hqx: Check the input data against the image size

[Michael Niedermayer]

On Tue, Jul 23, 2019 at 09:03:32AM +0200, Paul B Mahol wrote:
> On 7/23/19, Michael Niedermayer <michael at niedermayer.cc> wrote:
> > On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote:
> >> On 7/21/19, Michael Niedermayer <michael at niedermayer.cc> wrote:
> >> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote:
> >> >> On 7/21/19, Michael Niedermayer <michael at niedermayer.cc> wrote:
> >> >> > Fixes: Timeout (22 -> 7 sec)
> >> >> > Fixes:
> >> >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992
> >> >> >
> >> >> > Found-by: continuous fuzzing process
> >> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >> >> > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> >> >> > ---
> >> >> >  libavcodec/hqx.c | 4 ++++
> >> >> >  1 file changed, 4 insertions(+)
> >> >> >
> >> >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c
> >> >> > index bc24ba91d1..8639d77a41 100644
> >> >> > --- a/libavcodec/hqx.c
> >> >> > +++ b/libavcodec/hqx.c
> >> >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext
> >> >> > *avctx,
> >> >> > void
> >> >> > *data,
> >> >> >      avctx->height              = ctx->height;
> >> >> >      avctx->bits_per_raw_sample = 10;
> >> >> >
> >> >> > +    if (avctx->coded_width / 16 * (avctx->coded_height / 16) *
> >> >> > +        (100 - avctx->discard_damaged_percentage) / 100 > 8LL *
> >> >> > avpkt->size)
> >> >> > +        return AVERROR_INVALIDDATA;
> >> >>
> >> >> Why just this change and not something better?
> >> >
> >> > What would you prefer exactly ?
> >>
> >> Something that works with pure black video.
> >
> > Can you share the failing video file ?
> > I thought theres a minimum size of 1 vlc code (2 bit seem the smallest)
> > per 16x16 block. But quite possibly i might have missed something
> >
> 
> This is very disappointing. There is no freely available encoder for HQX.
> And the one who commits stuff need to make sure it does not introduce
> regressions.

The reviewer just has to explain how the problem he speaks of can
occur.

If we look at decode_slice_thread() each slice reads data from a distinct
input area (this is checked to be distinct in the code). So even the
same black slice cannot reuse the same representation.

decode_slice_thread calls decode_slice which calls decode_func
decode_func can be one of 4 implementations each reading at least
a minimum of 2 bit. so we have a minimum of 2 bits per macroblock
the calls happen at a granularity of 16x16 so theres a minimum of
2 bits per 16x16 block.
Its very possible that i have missed some path or case in this
analysis. But we wont really move forward based on riddles.
If you know of a path/case where a frame can be encoded with
less input data just explain that case and ill adjust the
patch accordingly. Otherwise the patch is stuck as i dont
know what case you speak of

PS: also there are no other return pathes in hqx_decode_frame()
all returns are error pathes so i dont see any shortcuts for
black frames which would bypass the minimum size

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190723/5a787514/attachment.sig>