fre 2024-03-22 klockan 03:25 +0100 skrev Michael Niedermayer: > Hi all > > we have code like > st->codecpar->ch_layout.nb_channels = avio_rb32(pb); > > and then somewhere there is some code that uses this by first > allocating > an array and that then hits OOM > (it was this here: > map = av_calloc(nb_channels, sizeof(*channel_layout->u.map));) > > is anyone against adding a max_channels field to AVFormatContext or > something > like that ?
Sounds reasonable, but also we have FF_SANE_NB_CHANNELS as James said. But a more proper solution is to use formal methods rather than fuzzers. Proofs beat fuzzing every day A more practical reason to limit channels is that there is without a doubt oodles of overflow bugs that trigger with channels >= INT32_MAX that don't trigger with channels == FF_SANE_NB_CHANNELS. Formal verification would discovered these of course, but we have nowhere near enough labour power to do that across the entire codebase. So limiting channels is a practical way to ensure channels*bytes_per_sample and so on can't overflow. A second question is: which users would need two billion channels? /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
