ReadXM: fix out-of-bounds reads from unvalidated dwMemPos (integer overflow)

[e-c-hansen]

Summary

CSoundFile::ReadXM can perform out-of-bounds reads on a crafted .xm file,
causing a SIGSEGV (denial of service). Confirmed on current master
(d1b97ed) and on the version shipped by Debian (libmodplug1 0.8.9.0).

Root cause

The instrument-sample loop advances dwMemPos by the attacker-controlled
samplesize[] values with no overflow guard:

for (UINT ismpd=0; ismpd<nsamples; ismpd++) {
    ...
    dwMemPos += samplesize[ismpd];      // unbounded
    if (dwMemPos >= dwMemLength) break;
}

On exit dwMemPos can be far past dwMemLength (e.g. 0xFFFFFFF8). The tail
parsers then trust it, each with an overflow-prone check:

• TEXT (load_xm.cpp:522): dwMemPos + 8 < dwMemLength — with
  dwMemPos = 0xFFFFFFF8, dwMemPos + 8 wraps to 0, so 0 < dwMemLength
  passes and *(DWORD*)(lpStream + dwMemPos) reads ~4 GB out of bounds.
• MIDI (load_xm.cpp:538): same shape.
• mix plugins (load_xm.cpp:587): LoadMixPlugins(lpStream + dwMemPos, …).

Because it is a cluster, guarding a single site just moves the crash to the
next (patching only TEXT relocates the SEGV into LoadMixPlugins).

Fix

Clamp dwMemPos to dwMemLength once, immediately after the sample loop.
Each tail parser already compares dwMemPos against dwMemLength and only
misbehaved when dwMemPos was allowed to exceed it, so a single root-cause
clamp neutralizes all three without touching each check:

if (dwMemPos > dwMemLength) dwMemPos = dwMemLength;

Testing

• The crashing input now parses cleanly under AddressSanitizer (0 errors).
• All reproducers found for this bug are resolved by the one clamp.
• Valid .xm, .mod, .s3m, and .it files parse unchanged.

Found via coverage-guided fuzzing (AFL++) with an ASan build. A 719-byte
minimized reproducer is available on request.