wai: reader limits for the extension formats' durations #258

Merged

dcharlot merged 5 commits from wai/extension-duration-limits into main 2026-10-15 01:04:12 -04:00

Conversation 0 Commits 5 Files changed 42 +3910 -297

dcharlot commented 2026-10-14 11:07:21 -04:00

Owner

Copy link

Stacked on #256, which is stacked on #255. This branch contains both PRs' commits unchanged. Until they merge, the diff here includes them; after they merge, this needs no rebase.

This PR closes the known gap #256 recorded: nothing bounded the durations that the extension formats declare.

Why

Score, haptic, audio scene, splat4d and film contracts each declare a length, and rendering allocates memory in proportion to it:

format	what rendering allocates
score	duration samples, outright
haptic	duration × 2 bytes per channel
audio scene	20 bytes per sample for the stereo mix
splat4d, film	a hash per frame for the receipts

Nothing bounded these declarations, so a contract a few bytes long could ask a renderer for unbounded memory.

The limits

Each extension's §2.1 now has a reader limit, shared with SPEC §2 through the always-on module wai::limits:

format	field	limit
score, haptics	duration × channels	2²⁷ samples
audio scene	duration	2²⁶ (so the stereo floor is 2²⁷ samples)
splat4d / film / reel	n_frames / frames / the shots' frames together	2²⁰ frames

A reader may refuse a contract past its limit (duration_too_long). It refuses when it reads the contract, before rendering anything.

Film ticks

A film frame's tick is start_tick + f × ticks_per_frame. That computation wrapped in release builds and panicked in debug builds. Now:

• a reader must refuse a schedule whose last tick passes 2⁶⁴ − 1, for a film and for each shot of a reel;
• Film::frame_tick saturates instead of wrapping;
• Reel::frame_tick uses checked arithmetic.

Checked

The new test. tests/extension_duration_limits.rs rewrites a committed vector of each format:

• exactly at its limit, it must read;
• one past it, it must be refused by name;
• a film schedule ending exactly at 2⁶⁴ − 1 must read, and one past it must be refused.

Falsified. With the readers as they were, all three tests fail.

Unchanged. The world, audio, haptic, splat4d, score and film corpora verify unchanged, and the 275 lib tests with the container features pass.

Guards. All checks are clean: tests-in-CI, spec refs, section refs, workflow concurrency, lockfiles, vanity metrics, comparative prose, public names.

Remaining gap, now recorded in SECURITY.md: replaying a world to a far tick still costs time in proportion to the tick. Memory is bounded; time is not.

🤖 Generated with Claude Code

**Stacked on #256, which is stacked on #255.** This branch contains both PRs' commits unchanged. Until they merge, the diff here includes them; after they merge, this needs no rebase. This PR closes the known gap #256 recorded: nothing bounded the durations that the extension formats declare. ## Why Score, haptic, audio scene, splat4d and film contracts each declare a length, and rendering allocates memory in proportion to it: | format | what rendering allocates | |---|---| | score | `duration` samples, outright | | haptic | `duration × 2` bytes per channel | | audio scene | 20 bytes per sample for the stereo mix | | splat4d, film | a hash per frame for the receipts | Nothing bounded these declarations, so a contract a few bytes long could ask a renderer for unbounded memory. ## The limits Each extension's §2.1 now has a reader limit, shared with SPEC §2 through the always-on module `wai::limits`: | format | field | limit | |---|---|---| | score, haptics | `duration × channels` | 2²⁷ samples | | audio scene | `duration` | 2²⁶ (so the stereo floor is 2²⁷ samples) | | splat4d / film / reel | `n_frames` / `frames` / the shots' frames together | 2²⁰ frames | A reader may refuse a contract past its limit (`duration_too_long`). It refuses when it reads the contract, before rendering anything. ## Film ticks A film frame's tick is `start_tick + f × ticks_per_frame`. That computation wrapped in release builds and panicked in debug builds. Now: - a reader must refuse a schedule whose last tick passes 2⁶⁴ − 1, for a film and for each shot of a reel; - `Film::frame_tick` saturates instead of wrapping; - `Reel::frame_tick` uses checked arithmetic. ## Checked **The new test.** `tests/extension_duration_limits.rs` rewrites a committed vector of each format: - exactly at its limit, it must read; - one past it, it must be refused by name; - a film schedule ending exactly at 2⁶⁴ − 1 must read, and one past it must be refused. **Falsified.** With the readers as they were, all three tests fail. **Unchanged.** The world, audio, haptic, splat4d, score and film corpora verify unchanged, and the 275 lib tests with the container features pass. **Guards.** All checks are clean: tests-in-CI, spec refs, section refs, workflow concurrency, lockfiles, vanity metrics, comparative prose, public names. **Remaining gap**, now recorded in SECURITY.md: replaying a world to a far tick still costs time in proportion to the tick. Memory is bounded; time is not. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 3 commits 2026-10-14 11:07:21 -04:00

wai: reader limits for picture, audio and video payloads ... f9215b5e01

The image, audio and AV1 decoders allocated what a payload declared, within whatever
their libraries allowed: the gap SECURITY.md listed first. SPEC §2 now sets reader
limits for them as it does for manifests and text: a picture up to 65 536 on a side
and 2^27 pixels, audio up to 2^27 samples counting every channel, AV1 up to 2^20
temporal units of such pictures. A reader may refuse past them (image_too_large,
audio_decoded_too_long, video_too_large), from what the payload declares; the writers
refuse the same. SPEC §5 now states the payload framing of the AV1, FLAC and Ogg Opus
capabilities, which only packaging §7 described for AV1.

Defects found and fixed on the way:
- flac_decode reserved STREAMINFO's declared total: 2^36 - 1 samples asked the
  allocator for 256 GiB before a sample was decoded.
- A 24-bit FLAC decoded to about ±256: the scale assumed 16 bits.
- opus_decode refused a stream whose source rate was not an Opus rate (44.1 kHz);
  RFC 7845 makes that field informational. Its output had no bound at all.
- png_decode and jpeg_decode guessed the format, so a PNG payload holding WebP decoded.
- jxl_decode refused deeper than 8 bits and returned 1 or 4 channels for grey or alpha.
- av1_decode decoded every packet and only then truncated to n; panicked on monochrome
  (empty chroma planes); misread 4:2:2, 4:4:4 and high bit depth; and let dav1d
  allocate whatever a sequence header declared. dav1d is now held to the header's
  h × w, a frame wider or taller than declared is refused, and av1_decode_each streams
  one frame at a time; the whole-output entry points refuse past 4 GiB from the header.

8-bit 4:2:0 frames decode byte for byte as before. AVIF decodes through libavif
directly with the reader limits as its decoder limits (libavif-image and the rav1e
build inside libavif are gone from the lockfile). include/wai.h is regenerated, which
also brings in the `# Safety` lines #241 added to the sources.

tests/media_decode_bounds.rs (14 tests, run by codec-wrappers) checks every limit at
its edge and one past it, on real payloads and on headers rewritten to declare more
than they hold. Falsified: the unbounded FLAC reserve, the 4:2:0-only conversion,
format guessing, an off-by-one pixel limit and the missing dav1d limit each fail it.
Green on the build host: those 14, fuzz_smoke, ffi_robustness, the text bounds and
memory tests, corpus_provenance, video_receipt, and the 193 lib tests with codecs.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: coverage-guided fuzzing of the reader, and the container reservations it found ... 3a6963ea0d

SECURITY.md's remaining known gap: fuzzing was a seeded-random smoke test, with no
coverage guidance for the manifest parser, the integer payload parsers or the codec
wrappers. wai-rs/fuzz/ adds four libFuzzer targets (cargo-fuzz, AddressSanitizer):

- envelope: version detection, the WAI1 and WAI2 readers, the listing form;
- int_payload: int_payload::decode_int against each (capability, parameter set) pair
  the integer conformance corpus commits, the first byte choosing the pair;
- media: the picture, audio, video and text decoders of the floor and the recommended
  set, the first byte choosing the decoder;
- containers: the extension containers (world, causal op, film, reel, score, haptic,
  splat4d, audio scene).

`seeds` builds the corpora from the repository: every committed envelope, integer
payload and container, and a valid payload per decoder from the reference writers.
`run.sh` runs each target for a given time, tells a find (exit 1, input kept in
fuzz/artifacts) from a tool failure (exit 2), and builds with --no-cfg-fuzzing because
rav1e depends on libfuzzer-sys under cfg(fuzzing), which left wai's cdylib with an
undefined symbol. wai-fuzz.yml runs each target for 15 minutes nightly on the macOS
runner (which has the codec libraries), never per pull request, keeping the corpus on
the CI volume between nights. wai-rs's one multi-line inline table (c2pa) is put on one
line: cargo-fuzz's TOML parser rejects it.

Found in the containers target's first seconds: the audio scene reader reserved a
u32 count of entries read from the input before reading one, so a few bytes asked for
48 GiB. The world, reel, score, haptic and splat4d readers did the same. Each now
reserves no more than its remaining bytes could hold. tests/container_reservations.rs
rewrites a committed vector of each to declare 2^32 - 1 entries in four bytes and
requires a refusal with no single allocation past a few megabytes, through an allocator
that records the largest request and refuses past 256 MiB; on the old readers the world
asset table alone asked for 256 GiB (falsified). wai-conformance runs it on every leg.

SECURITY.md now says what is fuzzed, and keeps two gaps: the C libraries are not
instrumented, and the extension formats' declared durations have no reader limit yet
(rendering allocates in proportion; reading is bounded).

Smoke runs on the build host: envelope, int_payload and media 120 s each, nothing
found; containers found the above, then ran 300 s clean once fixed. Green there: the new
test, and the 275 lib tests with the container features. Clean: tests-in-CI, spec and
section refs, workflow concurrency, lockfiles, vanity metrics, comparative prose,
public names.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: reader limits for the extension formats' durations ... 161d147767

A score, haptic signal, audio scene, splat4d clip or film declares its length in its
contract, and rendering allocates in proportion: a score's mixdown allocated `duration`
samples outright, a haptic channel `duration` × 2 bytes, a scene's stereo mix 20 bytes a
sample, and the splat4d and film receipts a hash a frame. Nothing bounded the
declaration, so a few bytes could ask a renderer for more memory than any machine has.
SECURITY.md recorded it as a gap when the fuzzing PR found the reader-side reservations.

Each extension's contract section (score, haptics, spatial-audio, volumetric,
linear-film and its reel) now has a reader limit shared with SPEC §2, through a new
always-on module `wai::limits`:
- score and haptics: `duration × channels` at most 2^27 samples;
- audio scene: `duration` at most 2^26, so the stereo floor is at most 2^27 samples;
- splat4d `n_frames`, film `frames`, a reel's shots together: at most 2^20 frames.
A reader may refuse past them (`duration_too_long`) when it reads the contract, before
anything is rendered; a conforming encoder writes none.

The film schedule's tick, `start_tick + f × ticks_per_frame`, wrapped in release builds
and panicked in debug ones. A reader must now refuse a schedule whose last tick passes
2^64 - 1 (a film's, and each shot's of a reel); `Film::frame_tick` saturates and
`Reel::frame_tick` uses checked arithmetic.

tests/extension_duration_limits.rs rewrites a committed vector of each format to declare
exactly its limit (it reads) and one past it (refused by name), and checks the film
schedule ending at 2^64 - 1 (reads) and past it (refused). Falsified: with the readers
as they were, all three tests fail. The world, audio, haptic, splat4d, score and film
corpora verify unchanged; the 275 lib tests with the container features pass. CI runs
the test beside container_reservations on every leg.

SECURITY.md drops the gap and keeps the one this exposes: replaying a world to a far
tick costs time in proportion (memory is bounded, time is not).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-14 12:35:31 -04:00

Merge main into wai/extension-duration-limits ... 0da93176af

# Conflicts:
#	wai/CHANGELOG.md

dcharlot added 1 commit 2026-10-14 19:53:43 -04:00

fuzz: the seed writer lives under src/bin, where cargo and the orphan check find it ... b07ce38a6b

`no-vanity-metrics / No new orphan source files` flagged wai/wai-rs/fuzz/src/seeds.rs:
a [[bin]] declared by an explicit path under src/ is reached by no `mod`, so the
check, which knows cargo's auto-discovered roots (src/bin/*.rs among them), counted it
as never compiled. It is the `seeds` binary run.sh builds; under src/bin/ it is both.
The check now reports no new orphans (25 pinned, 25 expected).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit aac73b5cb2 into main 2026-10-15 01:04:12 -04:00

dcharlot referenced this pull request from a commit 2026-10-15 01:04:13 -04:00

Merge pull request 'wai: reader limits for the extension formats' durations' (#258) from wai/extension-duration-limits into main

dcharlot referenced this pull request from a commit 2026-10-15 01:09:46 -04:00

Merge main (with #258) into wai/d2c-m2-m3

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!258

No description provided.