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

[Michael Niedermayer]

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 ...

thx

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/20200625/d7666de9/attachment.sig>