Skip to content

Fix crash on launch reading out of bounds when loading some WAV files#140

Merged
sezero merged 1 commit intosezero:masterfrom
thomashope:fix_crash_on_corrupt_wav
Jan 9, 2026
Merged

Fix crash on launch reading out of bounds when loading some WAV files#140
sezero merged 1 commit intosezero:masterfrom
thomashope:fix_crash_on_corrupt_wav

Conversation

@thomashope
Copy link
Copy Markdown
Contributor

Crash appears to be caused by reading out of bounds memory when checking for the presence of "mark" inside the LIST chunk of certain WAV files. Possibly caused by badly authored WAV files, though I'm not sure exactly what the expected format & behaviour is here.

Crash occurred when trying to run librequake v0.09-beta FULL version on an M2 Mac, but it does not look like a Mac specific issue imo.

Crash appears to be caused by the code reading out of bounds mem when
checking for the presence of "mark" inside the LIST chunk of certain WAV
files. Possibly caused by badly authored WAV files, though I'm not sure
exactly what the expected format & behaviour is here.

Crash occurred when launching librequake v0.09-beta FULL version on an
M2 Mac, though I do not think this is a Mac specific issue.
@sezero sezero merged commit 95e1c15 into sezero:master Jan 9, 2026
8 checks passed
@sezero
Copy link
Copy Markdown
Owner

sezero commented Jan 9, 2026

This is in. Thanks.

@sezero
Copy link
Copy Markdown
Owner

sezero commented Jan 9, 2026

@vsonnier, @andrei-drexler: vkquake and ironwail might need this, too.

@andrei-drexler
Copy link
Copy Markdown
Contributor

Thanks for the heads up!

@vsonnier
Copy link
Copy Markdown
Contributor

@sezero Thanks, cherry-picked on vk as well.

@vsonnier
Copy link
Copy Markdown
Contributor

vsonnier commented Jan 10, 2026

@sezero @thomashope Are we sure of that patch ? I now see that warning quite often in mods, of simply starting the Remaster :

vkQuake-Introduction-start-20260110-223426-00

Looking a bit closely this LIST + mark is really a non-standard way to lookup for loops, coming from Apple and completly deprecated, instead of using standardized smpl.

Anyway, the LIST chunk is a special case of a container that can contain litterally any sub-chunk, so if indeed LIST + mark must be checked >= 32 bytes, on the other end a smaller chunk is not an error so the Con_Warning ("%s contains bad LIST chunk\n", name); should be removed.

Thoughts ?

@thomashope
Copy link
Copy Markdown
Contributor Author

If it's considered valid to not have "mark" then the warning can be removed. I just assumed it was expected based on the existing code.

I'm happy to submit a PR to remove it, or create a new PR without it if you want to revert this one.

@vsonnier
Copy link
Copy Markdown
Contributor

vsonnier commented Jan 10, 2026

If it's considered valid to not have "mark" then the warning can be removed. I just assumed it was expected based on the existing code.

To be clear : for our case, if we have LIST AND 32 Bytes AND mark THEN we can process it, otherwise, in all other cases of LIST, just skip.
I'm not saying the presence of mark is optional and we should read the data anyway ! :)

So, we just need to remove

else
{
	Con_Warning("%s contains bad LIST chunk\n", name);
}

@sezero
Copy link
Copy Markdown
Owner

sezero commented Jan 10, 2026

Was I too hasty merging? Shameful of me.

Can you guys give me a tested follow-up patch?

@sezero
Copy link
Copy Markdown
Owner

sezero commented Jan 10, 2026

Can you guys give me a tested follow-up patch?

Is Novum/vkQuake@bd15df1 enough?

@vsonnier
Copy link
Copy Markdown
Contributor

Is Novum/vkQuake@bd15df1 enough?

I think so.

@sezero
Copy link
Copy Markdown
Owner

sezero commented Jan 11, 2026

Is Novum/vkQuake@bd15df1 enough?

I think so.

OK, applied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants