Fix out-of-bounds reads in drflac_read_pcm_frames_* when reusing an inconsistent frame (crafted FLAC)

[Alb3e3]

Title

Fix out-of-bounds reads in drflac_read_pcm_frames_* when reusing an inconsistent frame (crafted FLAC)

Body

Summary

Two crafted-FLAC inputs cause drflac_read_pcm_frames_s32/s16/f32 to read out of bounds of the
decoded-sample buffer, crashing in release/NDEBUG builds via the ordinary public API. Any app
that opens an untrusted .flac is affected (audio players, game engines, media tooling).

Both stem from the same place: the readers reuse the current frame whenever
currentFLACFrame.pcmFramesRemaining > 0, indexing
currentFLACFrame.subframes[j].pSamplesS32[iFirstPCMFrame + i] — but a crafted stream can leave the
current frame in a state that is inconsistent with the decoded-sample buffer.

Bug 1 — NULL subframe dereference after a seek

Sequence (public API): open → read → drflac_seek_to_pcm_frame(N) (returns success) → read → SEGV.
After the seek, pcmFramesRemaining > 0 but only subframes[0] is populated and subframes[1..]
are NULL (left over from a prior partially-decoded frame). The read dereferences NULL + iFirstPCMFrame.

• Repro: poc/min.flac (1106 bytes) + poc/repro.c. SEGV in drflac_read_pcm_frames_s32.

Bug 2 — heap-buffer-overflow on open (block size exceeds the maximum)

Reachable during drflac_open_memory_with_metadata alone (no seek). The current frame's
header.blockSizeInPCMFrames (e.g. 4096) is far larger than the STREAMINFO
maxBlockSizeInPCMFrames (e.g. 16) the decode buffer was sized for, while subframes[j] still point
at the small buffer. iFirstPCMFrame = blockSize - pcmFramesRemaining becomes huge (~2142), and the
read runs thousands of int32s past the allocation.

• Repro: poc/min_open_overflow.flac. ASan: heap-buffer-overflow ... READ of size 16, located
  thousands of bytes after the decoded-sample region allocated in drflac_open_with_metadata_private.

Root cause

drflac_read_pcm_frames_* trusts pcmFramesRemaining/header.blockSizeInPCMFrames/subframes[j]
without checking they are mutually consistent and consistent with the decoded-sample buffer (which
only holds maxBlockSizeInPCMFrames samples per channel). A crafted stream can leave that state
inconsistent after a seek or during open.

Fix

Before reusing the current frame in each of the three readers, verify it is self-consistent:

• header.blockSizeInPCMFrames <= maxBlockSizeInPCMFrames (buffer can hold it),
• pcmFramesRemaining <= header.blockSizeInPCMFrames (no iFirstPCMFrame underflow),
• every subframes[j].pSamplesS32 (j < channelCount) is non-NULL.
  If not, drop the stale frame (pcmFramesRemaining = 0) and decode a fresh one instead of
  dereferencing invalid state. (Could be factored into a small helper — happy to do that if preferred.)

Verification

• Fixes both reproducers and every fuzzer-found crashing input (1913 inputs).
• No regression: identical decoded frame counts before/after across all IETF FLAC decoder test
  files, and seek+read still works.
• Found with coverage-guided libFuzzer + ASan while fuzzing the seek / metadata paths (the in-repo
  harness only exercises open_memory + read_s32, never seeks).

[Alb3e3]

Runnable reproducers (standalone repro.c + the two crafted FLAC files, base64) here: https://gist.github.com/Alb3e3/46ae48b8c611c7cd9c1e43f8cb79307f

clang -O2 -g -DNDEBUG -fsanitize=address -I/path/to/dr_libs repro.c -o repro
./repro min.flac                # Bug 1: SEGV after a successful drflac_seek_to_pcm_frame
./repro min_open_overflow.flac  # Bug 2: heap-buffer-overflow during open (blockSize > maxBlockSize)

Both abort under ASan on current master (v0.13.4) and return cleanly with this PR. Verified across 1913 fuzzer-found crashing inputs (all fixed) with no regression on the IETF FLAC decoder test-file set (identical decoded frame counts, seek+read still works).

[mackron]

This has been fixed manually. Please do not submit AI-generated bug reports in the future.