plan: stb_vorbis heap overflow DONE (2d2c13e); claim removed

Per this file's own rule, the claim block goes when the work lands. Records
what is left: reporting the int truncation upstream to nothings/stb, which
still has it.

Author: crispasr integration

PLAN.md

@@ -827,75 +827,36 @@ second is small and unbreaks the platform immediately.
 Found while reproducing #369, and NOT that issue's cause: the reporter is on
 Windows CPU/Vulkan and sees wrong-language output, not silence.
 
-## CLAIMED 2026-09-07 — stb_vorbis heap overflow (security), root cause found
-
-Worktree: main (`/mnt/volume1/CrispASR`). Taking the OPEN item below.
-
-ROOT CAUSE, confirmed by arithmetic against the ASAN report, not inferred:
-
-    f->comment_list_length = get32_packet(f);                  // attacker uint32
-    f->comment_list = setup_malloc(f, sizeof(char*) * f->comment_list_length);
-    memset(f->comment_list, 0, sizeof(char*) * f->comment_list_length);
-
-`setup_malloc(vorb *f, int sz)` takes an **int**. With length = 1646854400,
-`8 * length` = 13,174,835,200 truncates to **289,933,312** — exactly the
-allocation size ASAN reported. The `memset` computes the same product but
-`sizeof` makes it `size_t`, so it is **13,174,835,200** — exactly the write size
-ASAN reported. THE ALLOCATION TRUNCATES AND THE CONSUMER DOES NOT. Same shape as
-the `resample_polyphase` n_out overflow fixed 2026-09-04 (int guard over a value
-that had already wrapped).
-
-UPSTREAM HAS NOT FIXED IT (checked, per the next-steps note below):
-nothings/stb master still has `setup_malloc(vorb *f, int sz)` and the same
-truncating multiply. So there is nothing to pull, the vendored patch is correct,
-and upstream is vulnerable by the same truncation — it lacks our `memset`, so
-instead of one 13 GB write its `for` loop walks `comment_list[i]` past the short
-allocation. Worth reporting upstream once ours is fixed.
-
-NOTE the memset is itself a CrispASR patch, added to fix an earlier fuzz crash
-(NULL comment_list freed by vorbis_deinit). It did not create the truncation, but
-it converted a gradual overflow into an immediate 13 GB one.
-
-Plan: bound `comment_list_length` before allocating so the product cannot
-truncate, size the allocation in `size_t`, craft a minimal Ogg reproducer into
-`tests/fuzz/regressions/` (which now actually replays — the copy step counts its
-seeds since 2026-09-04), and let `linux-fuzz-smoke` be the gate.
-
-## OPEN 2026-08-18 — stb_vorbis heap overflow on untrusted audio (security)
-
-Found incidentally by `linux-fuzz-smoke` on PR #371, which does not touch that
-code — fuzzing is stochastic and it happened to surface there. NOT that PR's
-fault, and it reproduces from the audio fuzzer, not from anything in the diff.
-
-    ==6684==ERROR: AddressSanitizer: heap-buffer-overflow
-    WRITE of size 13174835200 at 0x7f29bad7d000
-      #0 memset
-      #1 start_decoder(stb_vorbis*)        examples/stb_vorbis.c:3683
-      #2 stb_vorbis_open_memory            examples/stb_vorbis.c:5141
-      #3 stb_vorbis_decode_memory          examples/stb_vorbis.c:5419
-      #4 crispasr_webm_decode(...)         src/crispasr_audio.cpp:1405
-      #5 crispasr_audio_load               src/crispasr_audio.cpp:2801
-      #6 LLVMFuzzerTestOneInput            tests/fuzz/fuzz_audio_load.cpp:40
-
-    0x7f29bad7d000 is located 0 bytes after a 289933312-byte region
-    allocated by setup_malloc(stb_vorbis*, int)  examples/stb_vorbis.c:960
-
-A 13 GB `memset` past a 289 MB allocation: the size computation in
-`start_decoder` overflows or is not validated against the allocation
-`setup_malloc` actually made. Reachable through `crispasr_audio_load`, i.e. on
-ANY caller-supplied audio file — the CLI, the HTTP server's upload path, and
-every binding. That makes it a memory-safety issue on untrusted input, not just
-a fuzz curiosity.
-
-Severity note, honestly: a 13 GB write will fault almost immediately in
-practice, so the realistic outcome is a crash (DoS) rather than exploitable
-corruption. Worth fixing regardless, and worth checking whether a smaller,
-more controllable overflow is reachable from the same path.
-
-Next steps: reproduce locally with a fuzz build
-(`-DCRISPASR_FUZZ=ON -DCRISPASR_SANITIZE_ADDRESS=ON`), minimise the input, then
-decide between bounds-checking `start_decoder` and pulling a newer stb_vorbis.
-Check whether upstream stb has already fixed it before patching a vendored copy.
+## DONE 2026-09-07 — stb_vorbis heap overflow on untrusted audio (security)
+
+OPEN since 2026-08-18; fixed in `2d2c13ee`. Reachable from `crispasr_audio_load`
+— CLI, server upload, every binding.
+
+`setup_malloc` takes an **int**, so `sizeof(char*) * comment_list_length`
+truncated 13,174,835,200 to 289,933,312 and allocated that, while the `memset`
+on the next line computed the same product in `size_t` and wrote the full 13 GB.
+Both numbers match the original ASAN report exactly. One quantity, computed two
+ways, disagreeing across a boundary — the same shape as the
+`resample_polyphase` `n_out` overflow fixed 2026-09-04.
+
+Upstream nothings/stb has NOT fixed it (checked, as the item asked): master
+still carries the int-typed `setup_malloc` and the same multiply, so there was
+nothing to pull, and upstream is vulnerable by the same truncation. Worth
+reporting there — not yet done.
+
+Fixed at the call site (bound the count before the multiply: no truncation, and
+at most `stream_len/4` comments since each costs 4 bytes for its own length
+field) and at the choke point (`setup_malloc` rejects a negative `sz`). The
+vendor and per-comment strings on the same path got the same data-derived bound.
+
+`tests/fuzz/regressions/ogg-comment-count-int-overflow.ogg` (101 bytes,
+generated by `tools/gen-ogg-comment-fuzz-seed.py`) reproduces the original
+report exactly against the pre-fix decoder — same write size, same region size,
+same four stack frames and line numbers — and is clean after. The corpus
+README's previously-missing seed value (`0x3FFFFFFF`) was generated and tested
+and reproduces nothing today, so that row is retired rather than restored.
+
+REMAINING, small: report the truncation upstream to nothings/stb.
 
 ## Start here