This may be security relevant.
Based on 2 patches by chrome.
backport r19975 by michael
Originally committed as revision 22658 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
As discussed with Diego, we'll go for bumping micro in 0.5 and will
consider adding a RELEASEVERSION macro for trunk and 0.6 seperatly
Originally committed as revision 22087 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
First commit:
Make decode_init fail if the huffman tables are invalid and thus init_vlc fails.
Otherwise this will crash during decoding because the vlc tables are NULL.
Partially fixes ogv/smclock.ogv.1.101.ogv from issue 1240.
backport r19355 by reimar
Second commit:
Add extra validation checks to ff_vorbis_len2vlc.
They should not be necessary, but it seems like a reasonable precaution.
r19374 by reimar
Originally committed as revision 22076 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
now compiles with x264 API versions 65 up to 85
patch prepared by darkshikari
Originally committed as revision 22042 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
backported r20083 by diego
This commit does not introduce functional changes. It was applied in
order to faciliate reviewing the proposed libx264.c backport
Originally committed as revision 21832 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
Probably only DoS, init_get_bits sets buffer to NULL, thus causing a
NULL-dereference directly after.
backport r21426 by reimar
Originally committed as revision 21759 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
This might have been exploitable.
Fixes first crash of issue840.
backport r18388 by michael
Originally committed as revision 21757 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
as discussed with diego on irc, the spurious newline deletion and the
LIBAVCODEC_VERSION_MINOR bump are being reverted based on comments on
ffmpeg-cvslog by ramiro, uoti and michael.
See http://comments.gmane.org/gmane.comp.video.ffmpeg.cvs/28112 for the
full context.
Originally committed as revision 21755 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
Allows an application to register a callback that manages mutexes
on behalf of FFmpeg.
With this callback registered FFmpeg is fully thread safe.
backport r19025 by andoma
NB: This is a feature backport with little regression potential. It was
requested at FOSDEM 2010 by ben@geexbox.org for use by geexbox and the
enna mediacenter in the upcoming debian/squeeze and ubuntu/lucid
release.
Approved by DonDiego on #ffmpeg-devel
Originally committed as revision 21731 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
10_vorbis_submap_indexes.patch by chrome.
I am applying this even though Reimar had some comments to improve it as it fixes
a serious security issue and I do not want to leave such things unfixed.
backport r20001 by michael
Originally committed as revision 21730 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
23_vorbis_sane_partition.patch by chrome.
Also this should be better documented but i prefer not to leave potential
security issues open due to missing documentation.
r19996 by michael
Originally committed as revision 21729 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
12_vorbis_mode_indexes.patch by chrome
maybe exploitable
r19990 by michael
Originally committed as revision 21726 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
26_vorbis_mag_angle_index.patch by chrome
backport r19983 by michael
Originally committed as revision 21723 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
27_vorbis_residue_loop_error.patch by chrome
backport r19982 by michael
Originally committed as revision 21722 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
Based on 28_theora_malloc_checks.patch from the Google Chrome team.
backport r20008 by melanson
Originally committed as revision 21720 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
18_fix_theora_header_bit_len.patch by chrome
backport r19993 by michael
Originally committed as revision 21719 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
based on 31_mp3_outlen.patch by chrome.
backported r19988 by michael
Originally committed as revision 21718 to svn://svn.ffmpeg.org/ffmpeg/branches/0.5
This should not make any difference, yet some gcc versions on ARM
produce incorrect output without this fix.
Approved by Vitor.
Originally committed as revision 17698 to svn://svn.ffmpeg.org/ffmpeg/trunk
svq3_decode_slice_header() modifies the buffer used by the bitstream
reader. Some of the bitstream readers cache a few bytes of data, which
must be flushed after such a modification. Calling skip_bits_long(gb, 0)
achieves this.
Originally committed as revision 17680 to svn://svn.ffmpeg.org/ffmpeg/trunk
zero later. This should fix some valgrind warnings and hopefully FATE
ra144 test on ARM.
Originally committed as revision 17677 to svn://svn.ffmpeg.org/ffmpeg/trunk
