[FFmpeg-devel] [PATCH v2] tools/target_dec_fuzzer: use refcounted packets
James Almer
jamrial at gmail.com
Thu Aug 22 22:01:50 EEST 2019
On 8/21/2019 10:21 AM, James Almer wrote:
> On 8/21/2019 6:15 AM, Tomas Härdin wrote:
>> tis 2019-08-20 klockan 21:05 -0300 skrev James Almer:
>>> Should reduce date copying considerably.
>>>
>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>> ---
>>> Fixed a stupid mistake when checking the return value for av_new_packet().
>>> Still untested.
>>
>> Works great for me. Should make fuzzing faster overall, better use of
>> computing resources imo
>>
>>> @@ -186,6 +144,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
>>> error("Failed memory allocation");
>>>
>>> ctx->max_pixels = maxpixels_per_frame; //To reduce false positive OOM and hangs
>>> + ctx->refcounted_frames = 1;
>>
>> Could maybe have a comment that this is also to reduce false positives,
>> or that we want to focus on the new API rather than the old one
>
> Sure.
>
>>
>>> @@ -240,7 +199,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
>>> if (data + sizeof(fuzz_tag) > end)
>>> data = end;
>>>
>>> - FDBPrepare(&buffer, &parsepkt, last, data - last);
>>> + res = av_new_packet(&parsepkt, data - last);
>>> + if (res < 0)
>>> + error("Failed memory allocation");
>>> + memcpy(parsepkt.data, last, data - last);
>>
>> Is there some way to avoid this copy?
>
> I could create packets that point to a specific offset in the input
> fuzzed buffer, but that will mean they will lack the padding required by
> the API, not to mention the complete lack of control over said buffer's
> lifetime. This could either generate no issues, or make things go really
> wrong.
>
> So to make proper use of the AVPacket API, i need to allocate their
> reference counted buffers and populate them. After this patch the
> behaviour of this fuzzer is essentially the same as if it was a
> libavformat demuxer, creating packets out of an input file and
> propagating them to libavcodec.
> If the idea was to imitate an average library user's behavior, this
> pretty much is it.
>
>>
>> /Tomas
Will push with the requested comment added soon.
More information about the ffmpeg-devel
mailing list