| Message ID | 20240623230137.1749178-1-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/5] avcodec/aac/aacdec_usac: Test ac in usac | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
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@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?
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@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 [...]
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@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@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".
On Wed, Jun 26, 2024 at 08:58:27AM +0200, Lynne via ffmpeg-devel wrote: > 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@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@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-request@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". will apply with this thx [...]
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@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@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@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
On 26/06/2024 21:45, Andreas Rheinhardt wrote: > 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@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@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@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. I got an email from one of the developers who informed me that its supported in LATM. But, I have no samples, so patch welcome is fine for now.
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 */
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@niedermayer.cc> --- libavcodec/aac/aacdec_usac.c | 3 +++ 1 file changed, 3 insertions(+)