[FFmpeg-devel] [PATCH 1/8] lavc/cbs_h265: Disallow nonsensically large HVCC NAL arrays

Mark Thompson sw at jkqxz.net
Sun Sep 29 23:01:31 EEST 2019


On 29/09/2019 20:54, James Almer wrote:
> On 9/29/2019 1:45 PM, Mark Thompson wrote:
>> Fixes CID 1419833.
>> ---
>>  libavcodec/cbs_h2645.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> index 2dc261f7a5..185c458f61 100644
>> --- a/libavcodec/cbs_h2645.c
>> +++ b/libavcodec/cbs_h2645.c
>> @@ -695,7 +695,12 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
>>          nb_arrays = bytestream2_get_byte(&gbc);
>>          for (i = 0; i < nb_arrays; i++) {
>>              nal_unit_type = bytestream2_get_byte(&gbc) & 0x3f;
>> +
>>              nb_nals = bytestream2_get_be16(&gbc);
>> +            if (nb_nals > 64) {
> 
> Why not check for the actual limit of each ps type instead?

Mainly because that would require a big switch statement to determine the limit - since it's an early check for invalid streams which will fail later anyway I didn't want to clutter the code too much.

>                                                             This code
> will still try to parse the file if it reports more than 16 sps, for
> example, despite it being invalid.
> 
> Maybe also check for nb_nals == 0.

Is that actually invalid rather than just pointless?  I don't have a specification for this, and hevc_parse.c also accepts it (not checking the count at all).

>> +                // Too many NALs of this type - the header must be invalid.
>> +                return AVERROR_INVALIDDATA;
>> +            }
>>  
>>              start = bytestream2_tell(&gbc);
>>              for (j = 0; j < nb_nals; j++) {
>>

Thanks,

- Mark


More information about the ffmpeg-devel mailing list