FLAC Heap Overread when cuesheet in comment
$ ./cvlc -v
VLC media player 3.0.0-git Vetinari (revision 2.2.0-git-9965-g2b0e83c)
file: vlc/modules/demux/xiph_metadata.c
Comments are copied from the buffer as
psz_comment = strndup(p_data, n)
strndup copies to the first NULL so psz_comment does not have to be n bytes long.
For the case "cuesheet=" n - 9 is passed as the length of psz_comment[9]
else if( !strncasecmp(psz_comment, "cuesheet=", 9) )
{
xiph_ParseCueSheet( &hasMetaFlags, p_meta, '''&psz_comment[9], n - 9,'''
i_seekpoint, ppp_seekpoint );
}
xiph_ParseCueSheet iterates over the buffer of the specified length.
When you have a cuesheet comment that has a NULL byte within it a Heap overread is hit in xiph_ParseCueSheet as n - 9 is larger than the actual size of the comment
The attached file has only a comment block with the value being cuesheet=AA\0\0AAAA
You most likely won't see a crash if you don't have an ASAN build unless you modify it so that the comment is very large.
ASAN output
=================================================================
==11764==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000082cfc at pc 0x7efd86d3b9ca bp 0x7efd89b6cb30 sp 0x7efd89b6cb20
READ of size 1 at 0x602000082cfc thread T3
==11764==AddressSanitizer: while reporting a bug found another one.Ignoring.
[#0](https://code.videolan.org/videolan/vlc/-/issues/0) 0x7efd86d3b9c9 in xiph_ParseCueSheet demux/xiph_metadata.c:319
[#1](https://code.videolan.org/videolan/vlc/-/issues/1) 0x7efd86d3b9c9 in vorbis_ParseComment demux/xiph_metadata.c:552
[#2](https://code.videolan.org/videolan/vlc/-/issues/2) 0x7efd86d357bc in ParseComment demux/flac.c:651
[#3](https://code.videolan.org/videolan/vlc/-/issues/3) 0x7efd86d357bc in ReadMeta demux/flac.c:575
[#4](https://code.videolan.org/videolan/vlc/-/issues/4) 0x7efd86d357bc in Open demux/flac.c:151
[#5](https://code.videolan.org/videolan/vlc/-/issues/5) 0x7efd92ca272b in module_load modules/modules.c:183
[#6](https://code.videolan.org/videolan/vlc/-/issues/6) 0x7efd92ca329b in vlc_module_load modules/modules.c:275
[#7](https://code.videolan.org/videolan/vlc/-/issues/7) 0x7efd92cff50f in demux_NewAdvanced input/demux.c:259
[#8](https://code.videolan.org/videolan/vlc/-/issues/8) 0x7efd92d00190 in input_DemuxNew input/demux.c:361
[#9](https://code.videolan.org/videolan/vlc/-/issues/9) 0x7efd92d2ea69 in InputSourceNew input/input.c:2342
[#10](https://code.videolan.org/videolan/vlc/-/issues/10) 0x7efd92d36a70 in Init input/input.c:1303
[#11](https://code.videolan.org/videolan/vlc/-/issues/11) 0x7efd92d3a989 in Preparse input/input.c:509
[#12](https://code.videolan.org/videolan/vlc/-/issues/12) 0x7efd922ca493 in start_thread (/lib64/libpthread.so.0+0x7493)
[#13](https://code.videolan.org/videolan/vlc/-/issues/13) 0x7efd91e0b5dc in __clone (/lib64/libc.so.6+0xe95dc)
0x602000082cfc is located 0 bytes to the right of 12-byte region [0x602000082cf0,0x602000082cfc)
allocated by thread T3 here:
[#0](https://code.videolan.org/videolan/vlc/-/issues/0) 0x7efd933807d7 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libasan.so.1+0x577d7)
[#1](https://code.videolan.org/videolan/vlc/-/issues/1) 0x7efd91da3319 in strndup (/lib64/libc.so.6+0x81319)
Thread T3 created by T2 here:
[#0](https://code.videolan.org/videolan/vlc/-/issues/0) 0x7efd9334cdca in pthread_create (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libasan.so.1+0x23dca)
[#1](https://code.videolan.org/videolan/vlc/-/issues/1) 0x7efd92de4d72 in vlc_clone_attr posix/thread.c:482
[#2](https://code.videolan.org/videolan/vlc/-/issues/2) 0x7efd8a185d9f (+0xfed9f)
Thread T2 created by T0 here:
[#0](https://code.videolan.org/videolan/vlc/-/issues/0) 0x7efd9334cdca in pthread_create (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libasan.so.1+0x23dca)
[#1](https://code.videolan.org/videolan/vlc/-/issues/1) 0x7efd92de4d72 in vlc_clone_attr posix/thread.c:482
[#2](https://code.videolan.org/videolan/vlc/-/issues/2) 0x7fff11dd9f3f ([stack]+0x1df3f)
SUMMARY: AddressSanitizer: heap-buffer-overflow demux/xiph_metadata.c:319 xiph_ParseCueSheet
Shadow bytes around the buggy address:
0x0c0480008540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480008550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480008560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480008570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480008580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0480008590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00[04]
0x0c04800085a0: fa fa 00 fa fa fa 00 00 fa fa fd fd fa fa fd fd
0x0c04800085b0: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
0x0c04800085c0: fa fa fd fd fa fa fd fd fa fa 04 fa fa fa 05 fa
0x0c04800085d0: fa fa 07 fa fa fa 00 00 fa fa fd fa fa fa fd fa
0x0c04800085e0: fa fa fd fa fa fa 00 03 fa fa 00 03 fa fa 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Contiguous container OOB:fc
ASan internal: fe
==11764==ABORTING