Skip to content

crash in memcpy when playing corrupt webm video

Playing the video at streams.videolan.org/incoming/memcpy.webm causes a segfault in VLC at memcpy(). This happens in 64-bit Linux with VLC 1.1.4, and the current nightly in Windows 7.

The error is probably related to changing frame sizes in the stream, which cause the wrong dimensions to be used when copying the frame data.

This bug was originally reported elsewhere. You may have already heard of it via CERT. Not sure though, so filing it here separately to make sure you have heard about it.

--

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4c18700 (LWP 4087)]
0x00007ffff71bee48 in memcpy () from /lib/libc.so.6

(gdb) bt
[#0](https://code.videolan.org/videolan/vlc/-/issues/0)  0x00007ffff71bee48 in memcpy () from /lib/libc.so.6
[#1](https://code.videolan.org/videolan/vlc/-/issues/1)  0x00007fffe79c0e24 in ?? () from /usr/lib/vlc/plugins/demux/libmkv_plugin.so
[#2](https://code.videolan.org/videolan/vlc/-/issues/2)  0x00007fffe79c1525 in BlockDecode(demux_t*, libmatroska::KaxBlock*, libmatroska::KaxSimpleBlock*, long, long, bool) () from /usr/lib/vlc/plugins/demux/libmkv_plugin.so
[#3](https://code.videolan.org/videolan/vlc/-/issues/3)  0x00007fffe79c2c85 in ?? () from /usr/lib/vlc/plugins/demux/libmkv_plugin.so
[#4](https://code.videolan.org/videolan/vlc/-/issues/4)  0x00007ffff793270c in ?? () from /usr/lib/libvlccore.so.4
[#5](https://code.videolan.org/videolan/vlc/-/issues/5)  0x00007ffff7932f55 in ?? () from /usr/lib/libvlccore.so.4
[#6](https://code.videolan.org/videolan/vlc/-/issues/6)  0x00007ffff796bd04 in ?? () from /usr/lib/libvlccore.so.4
[#7](https://code.videolan.org/videolan/vlc/-/issues/7)  0x00007ffff76c6971 in start_thread () from /lib/libpthread.so.0
[#8](https://code.videolan.org/videolan/vlc/-/issues/8)  0x00007ffff721e92d in clone () from /lib/libc.so.6
[#9](https://code.videolan.org/videolan/vlc/-/issues/9)  0x0000000000000000 in ?? ()
(gdb) disas $rip-26, $rip+16
Dump of assembler code from 0x7ffff71bee2e to 0x7ffff71bee58:
   0x00007ffff71bee2e <memcpy+926>:	dec    %rcx
   0x00007ffff71bee31 <memcpy+929>:	mov    (%rsi),%rax
   0x00007ffff71bee34 <memcpy+932>:	mov    0x8(%rsi),%r8
   0x00007ffff71bee38 <memcpy+936>:	mov    0x10(%rsi),%r9
   0x00007ffff71bee3c <memcpy+940>:	mov    0x18(%rsi),%r10
   0x00007ffff71bee40 <memcpy+944>:	mov    0x20(%rsi),%r11
   0x00007ffff71bee44 <memcpy+948>:	mov    0x28(%rsi),%r12
=> 0x00007ffff71bee48 <memcpy+952>:	mov    0x30(%rsi),%r13
   0x00007ffff71bee4c <memcpy+956>:	mov    0x38(%rsi),%r14
   0x00007ffff71bee50 <memcpy+960>:	movnti %rax,(%rdi)
   0x00007ffff71bee54 <memcpy+964>:	movnti %r8,0x8(%rdi)
End of assembler dump.
Edited by Rémi Denis-Courmont
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information