1328300 - soundtouch: heap-buffer-overflow READ [@soundtouch::TDStretchSSE::calcCrossCorr]

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Tyson Smith [:tsmith]]

Attachment: test_case.wav

This was found while fuzzing version 1.9.2 of soundtouch.

The included test application soundstretch bundled in the source was used to find this issue.

The application was built with Address Sanitizer (ASan) with assertions disabled. (CFLAGS="-DNDEBUG" CXXFLAGS="-DNDEBUG")

Run with following command:
./soundstretch test_case.wav out.wav -pitch=-3


ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000018d10 at pc 0x7fef7618625a bp 0x7ffeb1a72580 sp 0x7ffeb1a72578
READ of size 16 at 0x621000018d10 thread T0
    #0 0x7fef76186259 in soundtouch::TDStretchSSE::calcCrossCorr(float const*, float const*, double&) soundtouch/source/SoundTouch/sse_optimized.cpp:124:17
    #1 0x7fef76175d82 in soundtouch::TDStretch::seekBestOverlapPositionFull(float const*) soundtouch/source/SoundTouch/TDStretch.cpp:305:16
    #2 0x7fef76175be9 in soundtouch::TDStretch::seekBestOverlapPosition(float const*) soundtouch/source/SoundTouch/TDStretch.cpp:258:16
    #3 0x7fef76177401 in soundtouch::TDStretch::processSamples() soundtouch/source/SoundTouch/TDStretch.cpp:659:18
    #4 0x7fef76170a6d in soundtouch::FIFOSamplePipe::moveSamples(soundtouch::FIFOSamplePipe&) soundtouch/source/SoundTouch/../../include/FIFOSamplePipe.h:88:9
    #5 0x7fef76170a6d in soundtouch::SoundTouch::putSamples(float const*, unsigned int) soundtouch/source/SoundTouch/SoundTouch.cpp:334
    #6 0x4ef8a0 in process(soundtouch::SoundTouch*, WavInFile*, WavOutFile*) soundtouch/source/SoundStretch/main.cpp:200:9
    #7 0x4ef8a0 in main soundtouch/source/SoundStretch/main.cpp:314
    #8 0x7fef74eeb82f in __libc_start_main /build/glibc-t3gR2i/glibc-2.23/csu/../csu/libc-start.c:291
    #9 0x41a108 in _start (soundtouch/soundstretch+0x41a108)

0x621000018d10 is located 0 bytes to the right of 4112-byte region [0x621000017d00,0x621000018d10)
allocated by thread T0 here:
    #0 0x4eb980 in operator new[](unsigned long) (soundtouch/soundstretch+0x4eb980)
    #1 0x7fef7616ba1b in soundtouch::FIFOSampleBuffer::ensureCapacity(unsigned int) soundtouch/source/SoundTouch/FIFOSampleBuffer.cpp:174:25

SUMMARY: AddressSanitizer: heap-buffer-overflow soundtouch/source/SoundTouch/sse_optimized.cpp:124:17 in soundtouch::TDStretchSSE::calcCrossCorr(float const*, float const*, double&)
Shadow bytes around the buggy address:
  0x0c427fffb150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fffb160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fffb170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fffb180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c427fffb190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c427fffb1a0: 00 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffb1b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffb1c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffb1d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffb1e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c427fffb1f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==25678==ABORTING

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

any data accessed by the cross-correlation code isn't going to be easy to extract; sec-moderate

status = ? for all, since I don't know if this path can be hit in how firefox uses soundtouch. (padenot?)

padenot: Is there an upstream maintainer we can loop in?

Comment 2

[Paul Adenot (:padenot)]

This relies on having a completely invalid wav file that is never going to pass our multiple validation stages that happen before even touching the soundtouch code.

In particular, here, the bitrate and the sample-rate are way out of range compared to our (although quite permissive) limits, and the codec identifier is invalid. This results in a dialog that says that the file cannot be played (if using `HTMLMediaElement`) or calling the error callback (if using AudioContext.decodeAudioData).

The application used here does not seem to perform any validation, hence the crash.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

So, upstream bug, and maybe an area of fragility (depending on external code to block "bad" data), but not a bug in Firefox per se at this time.

Reducing fragility would be good, but not by any means critical

Comment 4

[C.M.Chang[:chunmin]]

As comment #2 said, this file won't be played when it's loaded by a HTMLMediaElement and it won't be accepted as an input for the latest soundstretch either. Our demuxer will return a NS_ERROR_DOM_MEDIA_METADATA_ERR since its duration is 0. The latest soundstretch won't process it since its sample-rate is 556806192. It's fixed in the upstream here: https://gitlab.com/soundtouch/soundtouch/commit/6e8d58cbcc2c283a889418386ac413e7ed5e5a07

In that change, files whose sample-rate is larger than 192000 won't be accepted anymore. We should update the libsoundtouch to do that check for us.

Comment 5

[C.M.Chang[:chunmin]]

Updating libsoundotuch in bug 1588233 also solve this issue. I am going to mark this is fixed.