[FFmpeg-devel] [PATCH 5/5] libavcodec/jpeg2000dec.c: Remove log2_chroma check in pixel format selection

[Gautam Ramakrishnan]

On Fri, Jun 26, 2020 at 3:14 AM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Fri, Jun 26, 2020 at 12:22:22AM +0530, Gautam Ramakrishnan wrote:
> > On Tue, Jun 23, 2020 at 8:04 AM Gautam Ramakrishnan
> > <gautamramk at gmail.com> wrote:
> > >
> > > On Tue, Jun 23, 2020 at 2:55 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > > >
> > > > Am Mo., 22. Juni 2020 um 04:57 Uhr schrieb Gautam Ramakrishnan
> > > > <gautamramk at gmail.com>:
> > > > >
> > > > > On Mon, Jun 22, 2020 at 1:54 AM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > > > > >
> > > > > > Am So., 21. Juni 2020 um 21:11 Uhr schrieb <gautamramk at gmail.com>:
> > > > > > >
> > > > > > > From: Gautam Ramakrishnan <gautamramk at gmail.com>
> > > > > > >
> > > > > > > The log2_chroma_wh is derived from the sample separations of the
> > > > > > > codestream if the file is a j2k codestream. Not sure if sample
> > > > > > > separation is same is subsampling and whether using sample
> > > > > > > separation values from the codestream to determine pixel format.
> > > > > >
> > > > > > What would get fixed by this change?
> > > > > >
> > > > > The p1_01.j2k image was not getting recognized by the native
> > > > > decoder due to this condition.
> > > >
> > > > In any case, this was missing from the commit message.
> > > >
> > > > > It would now get recognized. If this patch is fine,
> > > >
> > > > I wanted to suggest to add the following two lines after
> > > > the calls to pix_fmt_guess():
> > > >     if (s->avctx->pix_fmt == AV_PIX_FMT_NONE && ncomponents == 1)
> > > >         s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
> > > >
> > > I had tried this for testing initially. I placed this inside the
> > > if (i == possible_fmts_nb) check. It seemed to work correctly.
> > > I could possibly resend with this also, but I did not know this would
> > > be a good solution.
> > > > But p1_01.j2k does not get decoded with the change either here.
> > > >
> > > > > I would preferably remove this check at all places.
> > > >
> > > > I thought the check is needed but if fuzzing does not produce
> > > > invalid memory access for you, it may be ok.
> > > >
> > > I'll run the fuzzer again carefully.
> > I ran the fuzzer (zzuf) where I ran ffmpeg with input files p1_01.j2k
> > and p1_07.j2k.
> > I tried with seeds from 0 to 10000.
> > I tried error rates of 0.01, 0.1 and 0.5. There was no segfault. I
> > used the -c option as
> > I only wanted it to fuzz the .j2k files. I hope my configuration while
> > using zzuf was correct.
>
> from my command line history, i tested
> zzuf -C9 -s 0:100 ./ffmpeg -v -99 -i p1_07.j2k
>
> zzuf[s=8,r=0.004]: signal 11 (SIGSEGV)
> zzuf[s=12,r=0.004]: signal 11 (SIGSEGV)
> zzuf[s=52,r=0.004]: signal 11 (SIGSEGV)
> zzuf[s=81,r=0.004]: signal 11 (SIGSEGV)
> zzuf[s=93,r=0.004]: signal 11 (SIGSEGV)
> zzuf[s=97,r=0.004]: signal 11 (SIGSEGV)
>
> i didnt investigate these at all yet so they may be unrelated to the j2k
> decoder, but there where segfaults ...

I tried the same command. However, even if I remove the input file from ffmpeg,
i.e run
zzuf -C9 -s 0:100 ./ffmpeg -v -99, I get segfaults.
Is it possible that ffmpeg reads some other files which is getting fuzzed?
In a tutorial, I saw that using -c command line option with zzuf will ensure
only files which show up on command line will get fuzzed. When I run with
the -c argument, I get no segfaults
>
> thx
>





--
-------------
Gautam |