[FFmpeg-devel] [PATCH]Fix progressive jpgs with weird pix_fmts

[Michael Niedermayer]

On Sat, Jan 07, 2012 at 12:26:29PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> 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
variables

[...]


-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120107/8f06754f/attachment.asc>