Comment 13 for bug 690169

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:
http://git.videolan.org/?p=FFmpeg.git;a=commit;h=445f0a8b666a34e6402f6ae96c6804c8bc024baa

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:
http://git.videolan.org/?p=FFmpeg.git;a=commit;h=ec10d2d53999f6edf7d7b5ac88df263eccfb1fb0

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++){
        const int mb_xy= s->mb_index2xy[ i ];
        int f=0;
        int error= s->error_status_table[mb_xy];

        if(IS_INTRA(s->current_picture.mb_type[mb_xy])) f=MV_FROZEN; //intra //FIXME check
        if(!(error&MV_ERROR)) f=MV_FROZEN; //inter with undamaged MV

        fixed[mb_xy]= f;
        if(f==MV_FROZEN)
            num_avail++;
    }

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.