Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Badly formed files can cause `create_sample_table()` to OOM.

Aperta
  • Qualcosa non va?
#395 6 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
security

Direzione di ricerca

Inizia tracciando create_sample_table() e la gestione dei box stsc e stsz, quindi esamina come get_indices espone i dati analizzati. Confronta gli scenari di errore di Gecko Bugs 1661368 e 1814791, inclusi i conteggi di sample non corrispondenti o eccessivi. Il lavoro è completato quando si impedisce ai file malformati di causare un’allocazione arbitraria o OOM, preservando al contempo l’analisi dei file validi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

See Gecko Bug 1661368 and more recently Bug 1814791.

There is currently no validation of whether a file with an stsc box with a large sample count is actually referencing offsets that fall within the file, which allows create_sample_table() to allocate an arbitrarily large vector and OOM.

We could just set a configurable hard limit on the number of samples it can allocate, but I don't know if that's the best solution.

We can also fail early when the relevant sample boxes have mismatched sample counts, but I'm not sure if there are files that currently parse and break that rule, and as tnikkel pointed out, the fuzzer may still find a way to create a matching sample count that causes OOM. Might still be worth implementing this if it makes sense to fail that way.

I think the most ideal solution is instead to make create_sample_table() aware of the amount of data in the file that is currently available to the caller, and use the stsz box to determine how many samples the vector needs to allocate to reach EOF. For cases where the full size is not known beforehand, API users would have to call get_indices multiple times and be aware that their pointers will be invalid, but that doesn't seem like a difficult problem.

What I wonder is whether the available data is something that should be accessible from other parts of mp4parse as well, for example to allow the box parsing to indicate that it hit the end of the available data but can continue parsing when more data is available.

Feel free to let me know if this idea doesn't make sense, we can use this issue to brainstorm more solutions if necessary.

Lingua principale
Rust
Stelle
448
Fork
73
Merge medio
6g 4h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mozilla/mp4parse-rust

Tutte le issue di mozilla/mp4parse-rust

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.