[FFmpeg-devel] [PATCH 1/5] avcodec/aac/aacdec_usac: Test ac in usac

[Andreas Rheinhardt]

Lynne via ffmpeg-devel:
> On 26/06/2024 01:57, Michael Niedermayer wrote:
>> On Wed, Jun 26, 2024 at 01:35:18AM +0200, Lynne via ffmpeg-devel wrote:
>>> On 24/06/2024 01:01, Michael Niedermayer wrote:
>>>> ff_aac_usac_config_decode() needs AACDecContext to be set but some
>>>> callers
>>>> pass NULL.
>>>>
>>>> I have no real testcase to implement/test this, so failing in this case
>>>> seems safest.
>>>>
>>>> Fixes: member access within null pointer of type 'AACDecContext'
>>>> (aka 'struct AACDecContext')
>>>> Fixes:
>>>> 69435/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-5733527483121664
>>>>
>>>> Found-by: continuous fuzzing process
>>>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>>>> ---
>>>>    libavcodec/aac/aacdec_usac.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/libavcodec/aac/aacdec_usac.c
>>>> b/libavcodec/aac/aacdec_usac.c
>>>> index 132ffee9c20..4856c1786b7 100644
>>>> --- a/libavcodec/aac/aacdec_usac.c
>>>> +++ b/libavcodec/aac/aacdec_usac.c
>>>> @@ -348,6 +348,9 @@ int ff_aac_usac_config_decode(AACDecContext *ac,
>>>> AVCodecContext *avctx,
>>>>        int map_pos_set = 0;
>>>>        uint8_t layout_map[MAX_ELEM_ID*4][3] = { 0 };
>>>> +    if (!ac)
>>>> +        return AVERROR_PATCHWELCOME;
>>>> +
>>>>        memset(usac, 0, sizeof(*usac));
>>>>        freq_idx = get_bits(gb, 5); /* usacSamplingFrequencyIndex */
>>>
>>> This doesn't seem possible at all.
>>> There are 2 callers, parse_audio_preroll and
>>> decode_audio_specific_config_gb. Both of these will crash way before the
>>> function is called.
>>>
>>> Could you at least get a backtrace?
>>
>> sure
>>
>> libavcodec/aac/aacdec_usac.c:402:39: runtime error: member access
>> within null pointer of type 'AACDecContext' (aka 'struct AACDecContext')
>> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
>> libavcodec/aac/aacdec_usac.c:402:39 in
>> AddressSanitizer:DEADLYSIGNAL
>> =================================================================
>> ==215602==ERROR: AddressSanitizer: SEGV on unknown address
>> 0x000000005b10 (pc 0x00000154771e bp 0x7ffcf5049e90 sp 0x7ffcf5049e70 T0)
>> ==215602==The signal is caused by a READ memory access.
>>      #0 0x154771d in av_channel_layout_uninit
>> ffmpeg/libavutil/channel_layout.c:439:25
>>      #1 0x57346e in ff_aac_usac_config_decode
>> ffmpeg/libavcodec/aac/aacdec_usac.c:402:9
>>      #2 0x500a0a in decode_audio_specific_config_gb
>> ffmpeg/libavcodec/aac/aacdec.c:1050:20
>>      #3 0x50a542 in latm_decode_audio_specific_config
>> ffmpeg/libavcodec/aac/aacdec_latm.h:80:21
>>      #4 0x4f8638 in read_stream_mux_config
>> ffmpeg/libavcodec/aac/aacdec_latm.h:160:24
>>      #5 0x4f8638 in read_audio_mux_element
>> ffmpeg/libavcodec/aac/aacdec_latm.h:233
>>      #6 0x4f8638 in latm_decode_frame
>> ffmpeg/libavcodec/aac/aacdec_latm.h:275
>>      #7 0x68f26f in decode_simple_internal
>> ffmpeg/libavcodec/decode.c:429:20
>>      #8 0x68f26f in decode_simple_receive_frame
>> ffmpeg/libavcodec/decode.c:600
>>      #9 0x68f26f in decode_receive_frame_internal
>> ffmpeg/libavcodec/decode.c:631
>>      #10 0x68dc9d in avcodec_send_packet
>> ffmpeg/libavcodec/decode.c:721:15
>>      #11 0x4d1e55 in LLVMFuzzerTestOneInput
>> ffmpeg/tools/target_dec_fuzzer.c:534:25
>>
>>
>> [...]
>>
>>
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> 
> This patch actually is correct.
> USAC in LATM is not supported AFAIK.
> 
> LGTM with a note like:
> "Happens only when the LATM decoder is used, and USAC is not supported
> in LATM".
> 

But then it is not PATCHWELCOME, but INVALIDDATA.

- Andreas