On Tue, May 15, 2018 at 11:02 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Mon, May 14, 2018 at 01:31:42AM +0200, Hendrik Leppkes wrote: >> On Mon, May 14, 2018 at 1:07 AM, Michael Niedermayer >> <mich...@niedermayer.cc> wrote: >> > Fixes: Timeout >> > Fixes: >> > 6383/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-6199846902956032 >> > >> > Found-by: continuous fuzzing process >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> > >> >> This does not seem like an issue to fix, but a fundamental change in >> the behavior of the codec. It currently properly honors all frame >> types, including "empty" frames, which results in proper constant >> frame rate output. >> After the change, it just flat out ignores those and discards them >> without any further consideration. >> >> Does not sound like a fuzzing or security related change to me, and >> possibly also quite the wrong thing to do. > > having a small code that outputs empty frames is a denial of service > issue (which is a security issue). The attacker can with almost no bandwidth > requirement cause the decode side to spend almost arbitrary amounts of > CPU doing nothing usefull. > > This problem is reduced when the copy case requires bandwidth proportional > to the resolution. As in a code per macroblock to skip it. > not one bit to make the player copy 1gb of data > > said differently this increases the cost to an attacker per CPU cycle > she causes on the player. > > In this particular case it also looks like that this is not > just a skip code but the decoder actually outputs empty frames on errors. > > besides security its also more efficient not to send cloned frames > though the whole chain (which forces every component to do duplicated work > on each). And we avoid this in other decoders as well. >
It makes no real difference if its less efficient or whatever - if a codec specification asks for this behavior, then our decoders should act accordingly. Generating vfr decoder output from a cfr input stream is not in any way a good idea. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
