[FFmpeg-devel] [PATCH]Fix progressive jpgs with weird pix_fmts
michaelni at gmx.at
Sat Jan 7 15:21:36 CET 2012
On Sat, Jan 07, 2012 at 12:26:29PM +0100, Carl Eugen Hoyos wrote:
> On Saturday 07 January 2012 03:27:52 am Michael Niedermayer wrote:
> > On Sat, Jan 07, 2012 at 03:17:36AM +0100, Carl Eugen Hoyos wrote:
> > > On Saturday 07 January 2012 02:59:06 am Michael Niedermayer wrote:
> > > > > Attached fixes the samples from ticket #892 for me.
> > > > >
> > > > > Please comment, Carl Eugen
> > > >
> > > > reset upscale* otherwise this is possibly exploitable if the width or
> > > > height or "pix_fmt" changes
> > >
> > > As in attached?
> > not enough
> > 1st frame sets upscale_h
> > 2nd frame changes width/height and branches via -1 from
> > ff_mjpeg_find_marker to the_end
> Iiuc, width/height can only be set in ff_mjpeg_decode_sof(), so new patch
> resets the value at the beginning of this function.
> > also wherever the variables are reset i suggest that a av_assert0 is
> > added to make sure the pixel format matches the expectation that is
> > theres enough space for chroma
> I don't understand:
> If the variables are reset (to 0), the code that may overwrite chroma /
> corrupt memory is not called, the variables are set together with the pix_fmt.
> Only s->ls change the pix_fmt later, upscale now also gets reset in this case.
my concern is if the code is changed in the future. A new code path
could be added that changes width/height and forgets reseting these
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel