-
Notifications
You must be signed in to change notification settings - Fork 42
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
Segmentation fault in mmreadUBYTE(MMFILE*) #56
Comments
I've been fuzzing libmodplug to find bugs in #57 and, despite finding one bug in that, I've mostly found a lot of bugs elsewhere instead. Particularly, there is some pretty bad cleanup and bounds checking in the MIDI loader, which is almost certainly the cause of this crash. There is also at least one place where the loader can return without clearing the reentrancy flag, leading to indefinite hangs. Whenever I get a run that hits over 1m executions I'll get my collection of fixes ready to submit as a patch (should be soon). Edit: it's here #58. I haven't confirmed that this patch fixed it on the OP's end, but I added the input file to the corpus and it hasn't crashed. |
The midi files support (load_mid, load_pat, load_abc) in libmodplug |
Many of the crash bugs and slow loads I've encountered fuzzing libmodplug so far are from the MIDI loader. This loader does not seem to have been written with stability or performance in mind. IMO MIDI support makes sense from the perspective of importing the data into a tracker for creating a module, but not so much for playback (as there are much better players). edit: this pretty much sums up the code quality of the MIDI loaders from what I've seen so far. static BYTE pat_gm_used[MAXSMP]; int pat_numsmp()
{
return strlen((const char *)pat_gm_used);
}
int pat_numinstr(void)
{
return strlen((const char *)pat_gm_used);
} |
The text was updated successfully, but these errors were encountered: