• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

Eyevinn / mp4ff / 35613915726
83%

Build:
DEFAULT BRANCH: master
Ran 21 Sep 2026 02:42PM UTC
Jobs 1
Files 214
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

21 Sep 2026 02:42PM UTC coverage: 82.147% (+0.02%) from 82.132%
35613915726

push

github

tobbee
fix(mp4): bound sgpd description_length against the box it came from

DecodeSgpdSR read the per-entry description_length as a uint32 off the
wire and never checked it against the bytes the sgpd box actually holds.
The sample group entry decoders size their slices from that value:
DecodeAlstSampleGroupEntry sizes two []uint16 from
(description_length - mandatorySize) / 4.

A 32-byte sgpd declaring description_length = 0xfffffff0 for an alst
entry therefore allocated 4096MB and ran about 1.07 billion loop
iterations before the read finally failed with "read too far in
SliceReader". The same box nested in a 48-byte moof > traf reproduced it
through mp4.DecodeFile, an amplification of roughly 90 million times.

The v0.56.0 alst fix bounded the opposite direction only: a roll_count
implying more bytes than description_length, caught by
`if uint64(length) <= mandatorySize`. A description_length larger than
the box carrying it went straight through.

Record the end of the box body on entry and check each
description_length against what is left of it before the entry is
decoded. The check also covers the DefaultLength branch, where every
entry takes the box-level default, and it is exact on both decode paths
since DecodeSgpd builds a SliceReader over just the body.

DecodeUnknownSampleGroupEntry, the other length-driven read, uses
sr.ReadBytes, which bounds n against the buffer and returns an empty
slice on overrun, so alst was the only entry decoder that pre-sized from
the declared length.

Two tests: a table over the boundary (4 fits, 5 is one byte over,
0xfffffff0, 0xffffffff) run through both DecodeBoxSR and DecodeBox, and
an allocation guard, since the old code also returned an error, just
after allocating 4GB.

Found by a fuzz target in a downstream CMAF ingest packager.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01McQTp8DPVsvbbbpyte4vAA

6 of 6 new or added lines in 1 file covered. (100.0%)

22188 of 27010 relevant lines covered (82.15%)

0.82 hits per line

Jobs
ID Job ID Ran Files Coverage
1 35613915726.1 21 Sep 2026 02:42PM UTC 214
82.15
GitHub Action Run
Source Files on build 35613915726
  • Tree
  • List 214
  • Changed 1
  • Source Changed 0
  • Coverage Changed 1
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • b9defed8 on github
  • Prev Build on master (#34841943948)
  • Next Build on master (#36253177160)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc