Finally, the VC1 crash affects current upstream git (when running VLC on top of libavcodec). The nature of the crash changes based on the build version. In all cases, there appears to be a stack overflow in the same piece of code that crashed with the WMV file:
for(i=0; i<s->mb_num; i++){
const int mb_xy= s->mb_index2xy[ i ];
int f=0;
int error= s->error_status_table[mb_xy];
In this case, MV_FROZEN is continually written into the fixed[] array, which is declared on the stack, well past its bounds, corrupting the stack. Depending on the build, this corruption may cause crashes in various places, but in 0.5.3, execution continues until returning to 0x03030303. This also probably deserves a separate CVE.
Ok, I've pinned down most of what's been happening here.
The crash with the WMV parsing (CVE-2010-3908) was fixed with the following upstream commit: git.videolan. org/?p= FFmpeg. git;a=commit; h=445f0a8b666a3 4e6402f6ae96c68 04c8bc024baa
http://
I'm not sure whether the fact that it fixed this issue was incidental or intentional.
The RealMedia heap corruption crashes were fixed with the following upstream commit: git.videolan. org/?p= FFmpeg. git;a=commit; h=ec10d2d53999f 6edf7d7b5ac88df 263eccfb1fb0
http://
I think these should probably get a separate CVE.
Finally, the VC1 crash affects current upstream git (when running VLC on top of libavcodec). The nature of the crash changes based on the build version. In all cases, there appears to be a stack overflow in the same piece of code that crashed with the WMV file:
for(i=0; i<s->mb_num; i++){ status_ table[mb_ xy];
const int mb_xy= s->mb_index2xy[ i ];
int f=0;
int error= s->error_
}
In this case, MV_FROZEN is continually written into the fixed[] array, which is declared on the stack, well past its bounds, corrupting the stack. Depending on the build, this corruption may cause crashes in various places, but in 0.5.3, execution continues until returning to 0x03030303. This also probably deserves a separate CVE.