Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uninitialized Read (and Divide by Zero) in ParseWave64HeaderConfig() #68

Closed
rohanpadhye opened this issue Mar 5, 2019 · 3 comments
Closed

Comments

@rohanpadhye
Copy link

@rohanpadhye rohanpadhye commented Mar 5, 2019

uninit-divzero-waveheader.wav.zip - contains fuzzed input

The parsing of the attached file uninit-divzero-waveheader.wav leads to a read of an uninitialized location in memory. The uninitialized read sometimes further leads to a divide-by-zero error. The uninitialized read can be uncovered using a tool such as Valgrind or MemorySanitizer. For example:

$ valgrind ./cli/wavpack uninit-divzero-waveheader.wav
==3921== Memcheck, a memory error detector
==3921== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3921== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==3921== Command: ./cli/wavpack uninit-divzero-waveheader.wav
==3921== 

 WAVPACK  Hybrid Lossless Audio Compressor  Linux Version 5.1.0
 Copyright (c) 1998 - 2019 David Bryant.  All Rights Reserved.

creating uninit-divzero-waveheader.wv,==3921== Conditional jump or move depends on uninitialised value(s)
==3921==    at 0x41016B: ParseWave64HeaderConfig (wave64.c:211)
==3921==    by 0x408A94: pack_file (wavpack.c:1777)
==3921==    by 0x404AE2: main (wavpack.c:1273)
==3921== 
==3921== 
==3921== Process terminating with default action of signal 8 (SIGFPE)
==3921==  Integer divide by zero at address 0x1002D83DC5
==3921==    at 0x410214: ParseWave64HeaderConfig (wave64.c:220)
==3921==    by 0x408A94: pack_file (wavpack.c:1777)
==3921==    by 0x404AE2: main (wavpack.c:1273)
==3921== 

It appears that this is an uninitialized read of the field WaveHeader.NumChannels on this line. This sometimes leads to a subsequent divide by zero on this line -- I guess the division instruction may or may not be executed based on what value is read for WaveHeader.NumChannels.

@rohanpadhye
Copy link
Author

@rohanpadhye rohanpadhye commented Mar 6, 2019

This is fixed now, thanks!

@rohanpadhye rohanpadhye closed this Mar 6, 2019
@dbry
Copy link
Owner

@dbry dbry commented Mar 6, 2019

Thanks for the reports and retest!

@utkarsh2102
Copy link

@utkarsh2102 utkarsh2102 commented Jan 14, 2021

uninit-divzero-waveheader.wav.zip - contains fuzzed input

Aw, it's interesting and weird that when I wget the zip and unzip it and run valgrind wavpack uninit-divzero-waveheader.wav, all I get is:

root@15b10a339dee:/home/elts/wavpack# valgrind wavpack uninit-divzero-waveheader.wav
==838== Memcheck, a memory error detector
==838== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==838== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==838== Command: wavpack uninit-divzero-waveheader.wav
==838== 

 WAVPACK  Hybrid Lossless Audio Compressor  Linux Version 4.70.0
 Copyright (c) 1998 - 2013 Conifer Software.  All Rights Reserved.

uninit-divzero-waveheader.wav is not a valid .WAV file!        
==838== 
==838== HEAP SUMMARY:
==838==     in use at exit: 0 bytes in 0 blocks
==838==   total heap usage: 7 allocs, 7 frees, 2,334 bytes allocated
==838== 
==838== All heap blocks were freed -- no leaks are possible
==838== 
==838== For counts of detected and suppressed errors, rerun with: -v
==838== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I am not sure why it gives me uninit-divzero-waveheader.wav is not a valid .WAV file!, any clue?

On the contrary:

root@15b10a339dee:/home/elts/wavpack# file uninit-divzero-waveheader.wav
uninit-divzero-waveheader.wav: Sony Wave64 RIFF data, WAVE 64 audio

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants