CVE request: Heap overflow in VLC 2.1.6 processing wav files

[Gustavo Grieco <gustavo.grieco () gmail com>]

Hi,

We found a buffer overflow in the parsing and processing of wav files in
VLC (version 2.1.6-0). It was tested in Ubuntu 14.04 (x86_64), but it will
probably affects other versions as well. Fortunately, it seems to be fixed
in the last release of VLC. Here you can see the gdb stack trace:

__memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116
116 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No existe el
archivo o el directorio.
(gdb) bt
#0 __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:116
#1 0x00007ffff71436e9 in memcpy (__len=4290773038, __src=<optimized out>,
__dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#2 AStreamPeekStream (s=<optimized out>, pp_peek=0x7fffea824988,
i_read=4294967276) at input/stream.c:1115
#3 0x00007fffdebb42b3 in ChunkFind (p_demux=p_demux@entry=0x7fffd4c01828,
fcc=fcc@entry=0x7fffdebb576b "fmt ", pi_size=pi_size@entry=0x7fffea824a3c)
at wav.c:522
#4 0x00007fffdebb4761 in Open (p_this=0x7fffd4c01828) at wav.c:166
#5 0x00007ffff716d178 in module_load (obj=obj@entry=0x7fffd4c01828,
m=m@entry=0x7b92b0, init=init@entry=0x7ffff716d0d0 <generic_start>,
args=args@entry=0x7fffea824b50) at modules/modules.c:185
#6 0x00007ffff716d72e in vlc_module_load (obj=obj@entry=0x7fffd4c01828,
capability=capability@entry=0x7ffff71a4059 "demux", name=0x7ffff71a43bb "",
name@entry=0x7fffd4c018e0 "", strict=<optimized out>,
probe=probe@entry=0x7ffff716d0d0
<generic_start>) at modules/modules.c:277
#7 0x00007ffff716dc04 in module_need (obj=obj@entry=0x7fffd4c01828,
cap=cap@entry=0x7ffff71a4059 "demux", name=name@entry=0x7fffd4c018e0 "",
strict=<optimized out>) at modules/modules.c:366
#8 0x00007ffff712cfbe in demux_New (p_obj=p_obj@entry=0x7fffd00009b8,
p_parent_input=p_parent_input@entry=0x7fffd00009b8,
psz_access=<optimized out>, psz_demux=0x7ffff71b9ca5 "",
psz_location=<optimized out>, s=<optimized out>, out=0x7fffd4000aa0,
b_quick=false)
at input/demux.c:188
#9 0x00007ffff7139d5d in InputSourceInit (p_input=p_input@entry=0x7fffd00009b8,
in=<optimized out>, psz_mrl=<optimized out>,
psz_forced_demux=psz_forced_demux@entry=0x0,
b_in_can_fail=b_in_can_fail@entry=false) at input/input.c:2535
#10 0x00007ffff713ab6b in Init (p_input=p_input@entry=0x7fffd00009b8) at
input/input.c:1225
#11 0x00007ffff713e0e6 in Run (obj=0x7fffd00009b8) at input/input.c:521
#12 0x00007ffff79a9182 in start_thread (arg=0x7fffea825700) at
pthread_create.c:312
#13 0x00007ffff74d247d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

It is evident that the memcpy operation has an abnormally large size
parameter (4290773038). Find attached a test case to reproduce it.

Regards,
Gustavo.