fix(stb_vorbis): heap overflow on untrusted audio — the allocation truncates, the consumer does not

Closes the PLAN item OPEN since 2026-08-18. Reachable from crispasr_audio_load,
so the CLI, the server's upload path and every binding.

THE MECHANISM, confirmed by arithmetic against the original ASAN report:

    f->comment_list_length = get32_packet(f);                   // attacker u32
    f->comment_list = setup_malloc(f, sizeof(char*) * length);  // int param
    memset(f->comment_list, 0, sizeof(char*) * length);         // size_t

setup_malloc's parameter is an `int`. With length = 1646854400 the product is
13,174,835,200, which truncates to 289,933,312 — EXACTLY the allocation size the
report showed. The memset computes the same product, but `sizeof` makes it a
size_t, so it is the full 13,174,835,200 — EXACTLY the write size the report
showed. One quantity, computed two ways, disagreeing across a boundary.

UPSTREAM HAS NOT FIXED IT. nothings/stb master still has `setup_malloc(vorb *f,
int sz)` and the same truncating multiply, so there was nothing to pull (which
is what the OPEN item asked to check first) and upstream is vulnerable by the
same truncation — lacking our memset, its `for` loop instead walks
comment_list[i] past the short allocation. Worth reporting there.

THE MEMSET IS ITSELF AN EARLIER CRISPASR PATCH, added to fix a different fuzz
crash (vorbis_deinit freeing an unwritten array). It did not create the
truncation; it converted a gradual overflow into an immediate 13 GB one.

THE FIX, two layers:
1. At the call site, bound the count before the multiply. Two bounds: the
   product must not truncate (INT_MAX/sizeof(char*), minus setup_malloc's
   (sz+7)&~7 rounding), and — derived from the data rather than picked — every
   comment costs at least 4 bytes for its own u32 length, so a file of N bytes
   cannot declare more than N/4 comments. That cannot reject a real file: one
   with C comments necessarily carries >= 4*C bytes. stream_len is 0 for
   stdio-backed streams, where only the first bound applies.
2. At the choke point, setup_malloc rejects a negative sz. Nearly every caller
   passes `sizeof(T) * count` computed in size_t, so this is not a one-off
   shape; a truncated value landing negative would otherwise reach malloc as a
   huge size_t.

The vendor string and the per-comment strings on the same path have the same
shape (attacker u32 length, then `len+1` in an int), so length_is_plausible()
bounds them by the same data-derived rule.

REPRODUCER, and it is verified in both directions.
tests/fuzz/regressions/ogg-comment-count-int-overflow.ogg, 101 bytes, generated
by tools/gen-ogg-comment-fuzz-seed.py. Against the pre-fix vendored decoder
under ASAN it reproduces the three-week-old report EXACTLY: WRITE of size
13174835200, 0 bytes after a 289933312-byte region, start_decoder:3683,
setup_malloc:960, stb_vorbis_open_memory:5141, stb_vorbis_decode_memory:5419 —
every size and every line number. After the fix the same input is rejected
cleanly. Reachability through crispasr_audio_load is established by the original
report's own stack, which is where it was found.

AND A CORRECTION TO THE CORPUS README. The seed it documented as missing
declared comment_list_length = 0x3FFFFFFF. I generated it and it reproduces
NOTHING against current code: 8 * 0x3FFFFFFF truncates to -8, so setup_malloc
fails and the header is rejected. Restoring that exact value would have added a
seed that gates nothing — the same disease as the empty replay set it was
written to fix. That row is retired rather than restored, with the reason.

Author: crispasr integration

examples/stb_vorbis.c

@@ -947,8 +947,29 @@ static void *make_block_array(void *mem, int count, int size)
    return p;
 }
 
+// CrispASR patch (security): is a declared byte-length plausible for this
+// stream? Every string in the comment header is preceded by its own u32 length
+// and must actually be present, so a declared length longer than the whole file
+// is a malformed header, not a big string. Derived from the data, so it cannot
+// reject a real file. stream_len is 0 for stdio-backed streams; there we can
+// only fall back to the int-overflow bound at the call site.
+static int length_is_plausible(vorb *f, int len)
+{
+   if (len < 0) return FALSE;
+   if (f->stream_len > 0 && (uint32) len > f->stream_len) return FALSE;
+   return TRUE;
+}
+
 static void *setup_malloc(vorb *f, int sz)
 {
+   // CrispASR patch (security): the parameter is an int, and nearly every
+   // caller passes `sizeof(T) * count` computed in size_t, so a large
+   // attacker-controlled count truncates on the way in — and can land
+   // negative. Callers then size their loops from the UNtruncated count.
+   // The comment_list case is bounded at its own call site (see start_decoder);
+   // this is the choke point that stops any other call site failing the same
+   // way, and a negative sz would otherwise reach malloc as a huge size_t.
+   if (sz < 0) return NULL;
    sz = (sz+7) & ~7; // round up to nearest 8 for alignment of future allocs.
    f->setup_memory_required += sz;
    if (f->alloc.alloc_buffer) {
@@ -3650,6 +3671,10 @@ static int start_decoder(vorb *f)
    if (!vorbis_validate(header))                    return error(f, VORBIS_invalid_setup);
    //file vendor
    len = get32_packet(f);
+   // CrispASR patch (security): same class as comment_list below — `len` is an
+   // attacker-controlled u32 and `len+1` can overflow int before it is even
+   // passed on. Reject an implausible length instead of allocating for it.
+   if (!length_is_plausible(f, len) || len == INT_MAX) return error(f, VORBIS_invalid_setup);
    f->vendor = (char*)setup_malloc(f, sizeof(char) * (len+1));
    if (f->vendor == NULL)                           return error(f, VORBIS_outofmem);
    for(i=0; i < len; ++i) {
@@ -3661,7 +3686,38 @@ static int start_decoder(vorb *f)
    f->comment_list = NULL;
    if (f->comment_list_length > 0)
    {
-      f->comment_list = (char**) setup_malloc(f, sizeof(char*) * (f->comment_list_length));
+      // CrispASR patch (security): BOUND THE COUNT BEFORE THE MULTIPLY.
+      //
+      // setup_malloc takes an `int`, so `sizeof(char*) * comment_list_length`
+      // is computed as size_t and then TRUNCATED on the way in, while the
+      // memset below computes the same product and does not. Found by
+      // linux-fuzz-smoke: with comment_list_length = 1646854400 the product is
+      // 13,174,835,200, truncating to 289,933,312 — and ASAN reported exactly
+      // that allocation size and exactly that write size. The allocation
+      // truncates; the consumer does not.
+      //
+      // Two bounds, cheapest first:
+      //   1. The count must be small enough that the product cannot truncate.
+      //      setup_malloc also rounds up with (sz+7)&~7, so leave that room.
+      //   2. Every comment costs at least 4 bytes in the packet — its own u32
+      //      length field — so a file of N bytes cannot legitimately declare
+      //      more than N/4 comments. This is derived from the data rather than
+      //      being a magic number, and it cannot reject a real file: one with
+      //      C comments necessarily carries at least 4*C bytes. stream_len is 0
+      //      for stdio-backed streams, so that arm is skipped there and bound 1
+      //      still applies.
+      //
+      // Upstream nothings/stb has the same truncating call and no fix as of
+      // 2026-09-07; it lacks this memset, so instead of one huge write its
+      // loop below walks comment_list[i] past the short allocation.
+      int max_comments = (int) (((size_t) INT_MAX - 7u) / sizeof(char*));
+      if (f->stream_len > 0 && (f->stream_len / 4u) < (uint32) max_comments)
+         max_comments = (int) (f->stream_len / 4u);
+      if (f->comment_list_length > max_comments) {
+         f->comment_list_length = 0;   // keep "length describes the array" true
+         return error(f, VORBIS_invalid_setup);
+      }
+      f->comment_list = (char**) setup_malloc(f, (int) (sizeof(char*) * (size_t) f->comment_list_length));
       // CrispASR patch: the length is already the ATTACKER-CONTROLLED value read
       // above, so returning here with a NULL array leaves the two out of step and
       // vorbis_deinit walks `comment_list_length` entries of a null pointer. Keep
@@ -3685,6 +3741,8 @@ static int start_decoder(vorb *f)
 
    for(i=0; i < f->comment_list_length; ++i) {
       len = get32_packet(f);
+      // CrispASR patch (security): as for the vendor string above.
+      if (!length_is_plausible(f, len) || len == INT_MAX) return error(f, VORBIS_invalid_setup);
       f->comment_list[i] = (char*)setup_malloc(f, sizeof(char) * (len+1));
       if (f->comment_list[i] == NULL)               return error(f, VORBIS_outofmem);
 

tests/fuzz/regressions/README.md

@@ -15,13 +15,22 @@ where that was practical, so it is deterministic and small enough to read.
 saying so. The glob matched nothing on every run from then on, and an empty
 replay set is indistinguishable from a passing one. `.gitignore` in this
 directory now re-includes the audio extensions, and the CI step counts what it
-copied and fails at zero. The ogg seed itself is LOST and has to be re-crafted
-from the description below before that row is a gate again.
+copied and fails at zero.
+
+**The lost ogg seed was re-crafted, and testing it produced a correction to the
+row below.** Its documented value, `comment_list_length = 0x3FFFFFFF`, does NOT
+reproduce anything against current code: `8 * 0x3FFFFFFF` truncates to −8, so
+`setup_malloc` fails and the header is rejected cleanly. Restoring that exact
+value would have put a seed in the corpus that gates nothing — the same shape as
+the empty replay set it was meant to fix. The value that *does* reproduce is
+`1646854400`, which is the one committed. `tools/gen-ogg-comment-fuzz-seed.py`
+generates either; pass a count to explore the space.
 
 | File | Bug | Fixed in |
 |---|---|---|
 | `wav-1hz-resample-oom.wav` | 344 KB, harvested from the run that found it (CI run 33840954769). A structurally valid RIFF/WAVE declaring `sampleRate = 1`. miniaudio resamples it to the 16 kHz target — 16000x — so 176 000 stored samples become 2.816e9 output frames, 11.3 GB, and the chunked decode loops doubled their buffer with no ceiling. Reachable from any surface that accepts a user file, including server upload. | `src/crispasr_audio.cpp`, `crispasr_max_decoded_frames()` bounds decoded frames against input size at all three loops |
-| `ogg-huge-comment-count.ogg` **(MISSING — see above)** | 102 bytes. Ogg/Vorbis comment header declaring `comment_list_length = 0x3FFFFFFF`. The allocation of `sizeof(char*) * length` fails, and stb_vorbis returned from the error path with the length still set and `comment_list` NULL — `vorbis_deinit` then indexed the null array. ASAN: `SEGV in vorbis_deinit`, reached from `crispasr_audio_load`. | `examples/stb_vorbis.c`, guard in `vorbis_deinit` + reset the length on the error path |
+| `ogg-comment-count-int-overflow.ogg` | 101 bytes, crafted (`tools/gen-ogg-comment-fuzz-seed.py`). Ogg/Vorbis comment header declaring `comment_list_length = 1646854400`. `setup_malloc` takes an **int**, so `sizeof(char*) * length` = 13,174,835,200 truncates to 289,933,312 and allocates that; the `memset` on the next line computes the same product in `size_t` and writes the full 13 GB. The allocation truncates, the consumer does not. Verified: against the pre-fix vendored decoder it reproduces the original report exactly — same write size, same region size, same `start_decoder:3683` / `setup_malloc:960` / `open_memory:5141` / `decode_memory:5419` frames — and is rejected cleanly after. | `examples/stb_vorbis.c`, bound the count before the multiply + reject a negative `sz` in `setup_malloc` |
+| ~~`ogg-huge-comment-count.ogg`~~ **(retired — its value gates nothing, see above)** | 102 bytes. Ogg/Vorbis comment header declaring `comment_list_length = 0x3FFFFFFF`. The allocation of `sizeof(char*) * length` fails, and stb_vorbis returned from the error path with the length still set and `comment_list` NULL — `vorbis_deinit` then indexed the null array. ASAN: `SEGV in vorbis_deinit`, reached from `crispasr_audio_load`. | `examples/stb_vorbis.c`, guard in `vorbis_deinit` + reset the length on the error path |
 
 ## Adding one
 

tests/fuzz/regressions/ogg-comment-count-int-overflow.ogg

@@ -0,0 +1,32 @@
+#!/usr/bin/env python3
+"""Craft the minimal Ogg that reaches stb_vorbis's comment_list allocation.
+
+No CRC is computed: stb_vorbis does not validate the page CRC (and its serial
+check is commented out), so the bytes that matter are the page framing, the
+identification packet it insists on, and the comment header's two u32 lengths.
+"""
+import struct, sys, pathlib
+
+def page(seq, flags, payload):
+    segs, rest = [], len(payload)
+    while rest >= 255:
+        segs.append(255); rest -= 255
+    segs.append(rest)
+    return (b"OggS" + bytes([0, flags]) + struct.pack("<q", 0)
+            + struct.pack("<I", 0x1234) + struct.pack("<I", seq)
+            + struct.pack("<I", 0)                      # CRC: not checked
+            + bytes([len(segs)]) + bytes(segs) + payload)
+
+# Identification packet — every field must survive stb_vorbis's validation or we
+# never reach the comment header. blocksize nibbles must be 6..13 with log0<=log1.
+ident = (b"\x01vorbis" + struct.pack("<I", 0) + bytes([1]) + struct.pack("<I", 44100)
+         + struct.pack("<iii", 0, 0, 0) + bytes([(8 << 4) | 8]) + bytes([1]))
+assert len(ident) == 30, len(ident)
+
+COUNT = int(sys.argv[2]) if len(sys.argv) > 2 else 1646854400
+comment = b"\x03vorbis" + struct.pack("<I", 0) + struct.pack("<I", COUNT)
+
+out = pathlib.Path(sys.argv[1])
+out.write_bytes(page(0, 0x02, ident) + page(1, 0x00, comment))
+prod = 8 * COUNT
+print(f"count={COUNT}  8*count={prod}  truncated to int32={prod % 2**32}  file={out.stat().st_size}B")