[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