[FFmpeg-trac] #9622(avformat:new): Skip samples overflow and negative in fragmented MP4

[FFmpeg]

#9622: Skip samples overflow and negative in fragmented MP4
-------------------------------------+-------------------------------------
             Reporter:  Matt         |                    Owner:  (none)
  Wolenetz                           |
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mov,         |               Blocked By:
  skip_samples, timestamp, seek      |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Description changed by Matt Wolenetz:

Old description:

> Summary of the bug:
> Negative int64_t result of mov_get_skip_samples() can result if the
> timestamps for samples in moofs decrease (e.g. first moof->traf->tfdt
> having base decode media time of Z, second moof-...time of Y, third ...
> of X, where Z>>Y>>X).
> Scenario: Seek to time X. Observe that the next packet read has time X
> but skip_samples (front discard) value in side data that is negative.
>
> Two questions:
> 1) Should such a stream instead produce parse error of some kind before
> emitting a packet with a negative skip_samples?
> How to reproduce: chromium fuzzer produced a case, but similar can be
> crafted manually. Reference https://crbug.com/1189939.
>
> 2) Return type of mov_get_skip_samples is larger than where it is used in
> caller, resulting in overflow/truncation. Is this only possible for
> malformed streams, which don't currently yield error but maybe should
> (see (1))? Or should the overflow/truncation be fixed or itself trigger
> some error?
>
> Downstream Chromium will likely just clip negative front_skip_samples to
> be non-negative, but such case may imply other issues in ffmpeg. Hence
> this bug.
> {{{
> % ffplay -loglevel trace -ss <time X> <reproFile>
>
> ...messages like:
> [mov,mp4,m4a,3gp,3g2,mj2 @ ...] demuxer injecting skip -925335552 /
> discard 0
> ...
> [opus @ ...] skip -925335552 / discard 0 samples due to side data
>
> ffplay version N-105440-gf23d3a5f8f Copyright (c) 2003-2022 the FFmpeg
> developers
>
> }}} this bug tracker.

New description:

 Summary of the bug:
 Negative int64_t result of mov_get_skip_samples() can result if the
 timestamps for samples in moofs decrease (e.g. first moof->traf->tfdt
 having base decode media time of Z, second moof-...time of Y, third ... of
 X, where Z>>Y>>X).
 Scenario: Seek to time X. Observe that the next packet read has time X but
 skip_samples (front discard) value in side data that is negative.

 Two questions:
 1) Should such a stream instead produce parse error of some kind before
 emitting a packet with a negative skip_samples?
 How to reproduce: chromium fuzzer produced a case, but similar can be
 crafted manually. Reference https://crbug.com/1189939.

 2) Return type of mov_get_skip_samples is larger than where it is used in
 caller, resulting in overflow/truncation. Is this only possible for
 malformed streams, which don't currently yield error but maybe should (see
 (1))? Or should the overflow/truncation be fixed or itself trigger some
 error?

 Downstream Chromium will likely just clip negative front_skip_samples to
 be non-negative, but such case may imply other issues in ffmpeg. Hence
 this bug.
 {{{
 % ffplay -loglevel trace -ss <time X> <reproFile>

 ...messages like:
 [mov,mp4,m4a,3gp,3g2,mj2 @ ...] demuxer injecting skip -925335552 /
 discard 0
 ...
 [opus @ ...] skip -925335552 / discard 0 samples due to side data

 ffplay version N-105440-gf23d3a5f8f Copyright (c) 2003-2022 the FFmpeg
 developers

 }}}

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9622#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker