After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783760 - wavparse: Processing wav file with blanck tag in metadata causes SIGSEGV
wavparse: Processing wav file with blanck tag in metadata causes SIGSEGV
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal critical
: 1.12.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-13 16:45 UTC by Alexey Elesin
Modified: 2017-06-13 21:13 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
wavparse: Actually clip to upstream size instead of size of the data chunk (1.37 KB, patch)
2017-06-13 21:11 UTC, Sebastian Dröge (slomo) 		committed Details | Review

Description Alexey Elesin 2017-06-13 16:45:36 UTC 
Specific WAV file with a blank tag in metadata causes gstreamer to SIGFAULT.

Steps to Reproduce: 
1) Any attempt to play the file using gstreamer will fail (gst-play, gst-launch + autoaudiosink etc)

Actual Results: Segmentation fault system error.
Build Date & Hardware: Gstreamer 1.12.2 compiled from source. 
Also happens on production server with Gstreamer 1.8.3 (ubuntu 16.04.2 package)

ffprobe info:
Input #0, wav, from '348d5e93057268519153.wav':
  Metadata:
    date            : 2017-05-19
    creation_time   : 18:39:53
    time_reference  : 7183553
    coding_history  : A=PCM,F=48000,W=16,M=stereo,T=Samplitude software 
                    : 
  Duration: 00:01:00.69, bitrate: 1536 kb/s
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s16, 1536 kb/s

Note the 5th line of metadata - name and value are missing.

After I've repacked wav file with "ffmpeg -i crash.wav -c:a copy out.wav" command ffprobe info is:
Input #0, wav, from 'echo.wav':
  Metadata:
    date            : 2017-05-19
    encoder         : Lavf56.40.101
  Duration: 00:01:00.69, bitrate: 1536 kb/s
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s16, 1536 kb/s

Note that there is no blank tags. No error is occuring.
Comment 1 Alexey Elesin 2017-06-13 16:47:25 UTC 
Link to the file:
https://drive.google.com/file/d/0B7JXjeBZwhgbbm4yblcwUU9XNkU/view?usp=sharing
Comment 2 Nicolas Dufresne (ndufresne) 2017-06-13 17:32:38 UTC 
Some interesting trace:
wavparse gstwavparse.c:1510:gst_wavparse_stream_headers:<wavparse0> Have 'adtl' LIST, size 4294967246

+ Trace 237572

  • #0 gst_wavparse_adtl_chunk
    at ../gst/wavparse/gstwavparse.c line 903
  • #1 gst_wavparse_stream_headers
    at ../gst/wavparse/gstwavparse.c line 1530
  • #2 gst_wavparse_loop
    at ../gst/wavparse/gstwavparse.c line 2183
  • #3 gst_task_func
    at ../gst/gsttask.c line 332
  • #4 g_thread_pool_thread_proxy
    at gthreadpool.c line 307
  • #5 g_thread_proxy
    at gthread.c line 784
  • #6 start_thread
    at pthread_create.c line 333
  • #7 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 105 






Comment 3


Nicolas Dufresne (ndufresne)





          2017-06-13 17:40:27 UTC
        



On the first warning:

"wavparse gstwavparse.c:1289:gst_wavparse_stream_headers:<wavparse0> Clipping chunk size to file size"

We endup with a size of -46 (was 4 before).






Comment 4


Sebastian Dröge (slomo)





          2017-06-13 21:11:29 UTC
        



Created attachment 353709 [details] [review]
wavparse: Actually clip to upstream size instead of size of the data chunk

There might be other chunks after the data chunk, so clipping the chunk
size with the data size can lead to a negative number and all following
calculations go wrong and cause crashes or worse.

This was introduced in 3ac119bbe2c360e28c087cf3852ea769d611b120.






Comment 5


Sebastian Dröge (slomo)





          2017-06-13 21:12:06 UTC
        



Attachment 353709 [details] pushed as a82e38d - wavparse: Actually clip to upstream size instead of size of the data chunk






Comment 6


Sebastian Dröge (slomo)





          2017-06-13 21:13:04 UTC
        



Also backported for 1.10.5