Le duodi 22 frimaire, an CCXXV, Michael Niedermayer a écrit : > OOM is a security issue under some(1) circumstances, one can hit OOM due > to too many pixels (or streams), this specific issue is fixed by the > options
> (1) For example a server process that dies due to it. Even if restarted > this can put load on the machine to be a effective was to DOS it If memory is limited by explicit limits at the OS level, then huge memory consumption in FFmpeg would not result in bursts of the OOM-killer but just return ENOMEM like a normal error. > completely independant of this, the option is needed to fuzz FFmpeg > efficiently as andreas explained > and also completely independant of this, the option is needed to > allow finding some fixable OOM bugs that i would like to fix For that case, I think that the idea of an independent branch is interesting. Or possibly: the option is implemented in a separate branch, and whenever it is needed, the commit is cherry-picked on top of head. But more importantly: since this is for convenience rather than security, it does not need to be backported to older releases, and therefore the compatibility issue is moot. The fixes for the bugs found by fuzzing, of course, can be backported. > Also its certainly true that this does not fix every OOM issue but > no bugfix that fixes a out of array read fixes every out of array read > either I would never oppose to a change on the grounds that it only does part of a task impossible to do completely. I think I denounced that kind of arguments recently about DCE :) Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel