There is a Heap-based Buffer Overflow occurring on an attempt to provide a malformed input file for conversion. The output of the command:
~/ver$ ./an -f -V 9 crashes/n\:000003 /dev/null
LAME 3.99.5 64bits (http://lame.sf.net)
Resampling: input -7.937 kHz output 8 kHz
polyphase lowpass filter disabled
Encoding crashes/n:000003 to /dev/null
Encoding as 8 kHz j-stereo MPEG-2.5 Layer III VBR(q=9)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
0/29219 ( 0%)| 0:00/ 0:00| 0:00/ 0:00| 0.0000x| 0:00
8 [0]
16 [0]
24 [0]
32 [0]
40 [0]
48 [0]
56 [0]
64 [0]
35:03-----------------------------------------------------------------------------------------
kbps % %
0.0 =================================================================
==7920==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c00000bf7c at pc 0x0000005d4cb4 bp 0x7fffa0b61c50 sp 0x7fffa0b61c48
READ of size 4 at 0x60c00000bf7c thread T0
#0 0x5d4cb3 (/home/kirit/ver/an+0x5d4cb3)
#1 0x57207d (/home/kirit/ver/an+0x57207d)
#2 0x5757fc (/home/kirit/ver/an+0x5757fc)
#3 0x506ae8 (/home/kirit/ver/an+0x506ae8)
#4 0x504c30 (/home/kirit/ver/an+0x504c30)
#5 0x5076d9 (/home/kirit/ver/an+0x5076d9)
#6 0x7f71386013f0 (/lib/x86_64-linux-gnu/libc.so.6+0x203f0)
#7 0x41c859 (/home/kirit/ver/an+0x41c859)
0x60c00000bf7c is located 4 bytes to the left of 128-byte region [0x60c00000bf80,0x60c00000c000)
allocated by thread T0 here:
#0 0x4cc360 (/home/kirit/ver/an+0x4cc360)
#1 0x5d1e6f (/home/kirit/ver/an+0x5d1e6f)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/kirit/ver/an+0x5d4cb3)
Shadow bytes around the buggy address:
0x0c187fff9790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c187fff97a0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c187fff97b0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x0c187fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c187fff97d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
=>0x0c187fff97e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa[fa]
0x0c187fff97f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c187fff9800: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c187fff9810: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x0c187fff9820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c187fff9830: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
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
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==7920==ABORTING
The process gives the following exit information when hooked with GDB:
Starting program: /home/kirit/ver/van -f -V 9 crashes/n:000003 /dev/null
LAME 3.99.5 64bits (http://lame.sf.net)
Resampling: input -7.937 kHz output 8 kHz
polyphase lowpass filter disabled
Encoding crashes/n:000003 to /dev/null
Encoding as 8 kHz j-stereo MPEG-2.5 Layer III VBR(q=9)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
0/29219 ( 0%)| 0:00/ 0:00| 0:00/ 0:00| 0.0000x| 0:00
8 [0]
16 [0]
24 [0]
32 [0]
40 [0]
48 [0]
56 [0]
64 [0]
35:03-----------------------------------------------------------------------------------------
kbps % %
0.0
Program received signal SIGSEGV, Segmentation fault.
0x00000000004736f3 in k_34_4 (x=<optimized out>, l3=<optimized out>) at vbrquantize.c:184
This is already fixed in CVS.
Thanks Robert. Is there a CVE associated with this already for <3.99.5?
Hi, Robert. I can seem to reproduce the bug even if I compile from HEAD. Is the fix in any particular branch?
Thanks!
No, the fix is in HEAD. How do you configure your build, does it use libsndfile for reading, or LAME native audio reader?
The fix should make sure, that LAME terminates, when the input sample rate is less than 1.
Your testfile gets rejected, when I try to encode it.
Hi, sorry for the confusion. For some reason the tarball I was exporting using the CVS viewer wasn't working... I had to anonymously clone and compile from there.
I can confirm this is fixed in VCS, and the relevant patch is attached if anyone is curious