From: James Almer <jamrial-at-gmail.com@ffmpeg.org> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH 1/4] avformat/iamf_parse: Check extradata size Date: Mon, 23 Jun 2025 12:26:34 -0300 Message-ID: <f02d81b2-ed4d-4997-a875-625d1081a834@gmail.com> (raw) In-Reply-To: <1081a00f-daf5-43ad-842b-9e0bbfc8165d@gmail.com> [-- Attachment #1.1.1: Type: text/plain, Size: 5240 bytes --] On 6/23/2025 12:14 PM, James Almer wrote: > On 6/23/2025 9:57 AM, Andreas Rheinhardt wrote: >> James Almer: >>> On 6/23/2025 9:44 AM, Michael Niedermayer wrote: >>>> On Fri, Jun 20, 2025 at 12:28:13AM +0200, Andreas Rheinhardt wrote: >>>>> Michael Niedermayer: >>>>>> Fixes: Assertion n>=0 && n<=32 failed at ./libavcodec/get_bits.h:406 >>>>>> Fixes: 398527871/clusterfuzz-testcase-minimized- >>>>>> ffmpeg_dem_IAMF_fuzzer-6602025714647040 >>>>>> >>>>>> Found-by: continuous fuzzing process https://github.com/google/oss- >>>>>> fuzz/tree/master/projects/ffmpeg >>>>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> >>>>>> --- >>>>>> libavformat/iamf_parse.c | 2 ++ >>>>>> 1 file changed, 2 insertions(+) >>>>>> >>>>>> diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c >>>>>> index 71497876ac3..330e01733dd 100644 >>>>>> --- a/libavformat/iamf_parse.c >>>>>> +++ b/libavformat/iamf_parse.c >>>>>> @@ -305,6 +305,8 @@ static int update_extradata(AVCodecParameters >>>>>> *codecpar) >>>>>> skip_bits(&gb, 4); >>>>>> put_bits(&pb, 4, codecpar->ch_layout.nb_channels); // set >>>>>> channel config >>>>>> ret = put_bits_left(&pb); >>>>>> + if (ret < 0) >>>>>> + return AVERROR_INVALIDDATA; >>>>>> while (ret >= 32) { >>>>>> put_bits32(&pb, get_bits_long(&gb, 32)); >>>>>> ret -= 32; >>>>> >>>>> There is only one way for put_bits_left() to return a negative >>>>> value: If >>>>> there is more data in the internal buffer than can be written out. And >>>>> this scenario is already a violation of the PutBit API. Given that the >>>>> size of the internal buffer depends upon the arch, it could be that >>>>> one >>>>> would have already hit an assert in case one is not using x64. In >>>>> other >>>>> words, your check is too late. >>>> >>>> the patches puprose was mainly to show that >>>> 3f9420132441345b7ccd57001f230bb98f655696 >>>> was insufficient to fix 398527871 >>>> >>>> I do not expect my patch would be the correct solution even if the >>>> check is done earlier. IAMF is cursed >>> >>> Does increasing buf from 6 bytes to 8 or more fix it? I see putbits may >>> do an AV_W*64(), so six bytes sounds like it was never safe. >>> >> That is only executed when the internal bit buffer is full; you will >> never reach it on x64. The problem is that you initialize the put bits >> buffer with FFMIN(codecpar->extradata_size, sizeof(buf)) instead of >> sizeof(buf). If this were not so, there would always be bits left. >> But this only fixes the API violations, it does not guarantee that the >> written data is actually correct. What is actually in the data that gets >> written in the loop? > The remaining bits in the GetBitContext buffer in order to fill the > PutBitContext buffer. > > The following probably fixes it, based on what you said. > >> diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c >> index 71497876ac..19c549d4ac 100644 >> --- a/libavformat/iamf_parse.c >> +++ b/libavformat/iamf_parse.c >> @@ -288,7 +288,7 @@ static int update_extradata(AVCodecParameters >> *codecpar) >> uint8_t buf[6]; >> int size = FFMIN(codecpar->extradata_size, sizeof(buf)); >> >> - init_put_bits(&pb, buf, size); >> + init_put_bits(&pb, buf, sizeof(buf)); >> ret = init_get_bits8(&gb, codecpar->extradata, size); >> if (ret < 0) >> return ret; >> @@ -312,6 +312,9 @@ static int update_extradata(AVCodecParameters >> *codecpar) >> put_bits(&pb, ret, get_bits_long(&gb, ret)); >> flush_put_bits(&pb); >> >> + if (get_bits_left(&gb) < 0) >> + return AVERROR_INVALIDDATA; >> + >> memcpy(codecpar->extradata, buf, put_bytes_output(&pb)); >> break; >> } Actually no, that broke FATE. This maybe: > diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c > index 71497876ac..0bd4696b83 100644 > --- a/libavformat/iamf_parse.c > +++ b/libavformat/iamf_parse.c > @@ -288,7 +288,7 @@ static int update_extradata(AVCodecParameters *codecpar) > uint8_t buf[6]; > int size = FFMIN(codecpar->extradata_size, sizeof(buf)); > > - init_put_bits(&pb, buf, size); > + init_put_bits(&pb, buf, sizeof(buf)); > ret = init_get_bits8(&gb, codecpar->extradata, size); > if (ret < 0) > return ret; > @@ -304,7 +304,10 @@ static int update_extradata(AVCodecParameters *codecpar) > > skip_bits(&gb, 4); > put_bits(&pb, 4, codecpar->ch_layout.nb_channels); // set channel config > - ret = put_bits_left(&pb); > + ret = get_bits_left(&gb); > + if (ret < 0) > + return AVERROR_INVALIDDATA; > + ret = FFMIN(ret, put_bits_left(&pb)); > while (ret >= 32) { > put_bits32(&pb, get_bits_long(&gb, 32)); > ret -= 32; [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] [-- Attachment #2: Type: text/plain, Size: 251 bytes --] _______________________________________________ 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".
next prev parent reply other threads:[~2025-06-23 15:26 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-06-19 3:04 Michael Niedermayer 2025-06-19 3:04 ` [FFmpeg-devel] [PATCH 2/4] tools/target_dec_fuzzer: Adjust RV60 threshold Michael Niedermayer 2025-06-23 12:48 ` Michael Niedermayer 2025-06-19 3:04 ` [FFmpeg-devel] [PATCH 3/4] avcodec/sanm: Check w, h for subversion < 2 Michael Niedermayer 2025-06-23 12:47 ` Michael Niedermayer 2025-06-19 3:04 ` [FFmpeg-devel] [PATCH 4/4] avcodec/sanm: Check thet left/top is within the w/h Michael Niedermayer 2025-06-19 22:28 ` [FFmpeg-devel] [PATCH 1/4] avformat/iamf_parse: Check extradata size Andreas Rheinhardt 2025-06-23 12:44 ` Michael Niedermayer 2025-06-23 12:47 ` James Almer 2025-06-23 12:57 ` Andreas Rheinhardt 2025-06-23 15:14 ` James Almer 2025-06-23 15:26 ` James Almer [this message] 2025-06-23 14:19 ` Michael Niedermayer 2025-06-23 14:24 ` Michael Niedermayer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=f02d81b2-ed4d-4997-a875-625d1081a834@gmail.com \ --to=jamrial-at-gmail.com@ffmpeg.org \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git