Segmentation fault in mmreadUBYTE(MMFILE*)

[konstanty]

Segmentation fault in mmreadUBYTE(MMFILE*)

[AliceLR]

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.

[sezero]

The midi files support (load_mid, load_pat, load_abc) in libmodplug
is bad and should die. I specifically disable it in my fork, SDL_sound
removed it in its fork and went back to timidity.

[AliceLR]

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);
}

[AliceLR]

This should be fixed via #66 / #67 and maybe #76.