Incorrect header in wav files can lead to enormous memory allocations (+4gb)

[ChichiMsdk]

When loading a wav file using SDL_LoadWAV(fname, &spec, &audio_buf, &wav_length), an incorrect header that reports an arbitrary amount of data could lead to several gb of allocations performed on the audio_buf
Despite knowing the correct size of the audio file since it is correctly returned by wav_length

In my case the file was around 70mb and reported it's size of -1 and therefore SDL allocated the signed int max 32bits value (+4gb !)

EDIT: I also modified the wav file manually and replaced to number by something close to reality (80mb) and the allocation varied accordingly btw

I guess we should instead allocate the correct amount by checking the header against the size calculated with wav_length

[icculus]

Do you happen to have a .wav file that triggers this that you can upload here, so I'm definitely fixing the right problem?

[ChichiMsdk]

Yes but github won't allow me to upload .wav nor files > 10mb so here's a wetransfer link:
https://we.tl/t-wUrId8xBfx
I should also mention that this file was most likely converted and downloaded from youtube so clearly not a "regular well crafted wav file" here
Screenshot for more explanation of what I meant

[icculus]

Thanks! I'll grab this later today!

[slouken]

@ChichiMsdk, can you repost the link? It's expired here.

[ChichiMsdk]

@slouken I don't have the file anymore but this could be easily reproduced by manipulating the 4 bytes after "data" in the wav header for any wav files.
I grabbed some youtube video that I converted to wav directly using this online tool https://cobalt.tools/.

I believe that the wrong information in the header comes from this tool