From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 82BA343905 for ; Mon, 4 Jul 2022 00:27:43 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8AF8B68B98A; Mon, 4 Jul 2022 03:27:40 +0300 (EEST) Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com [209.85.160.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4D13568B8E1 for ; Mon, 4 Jul 2022 03:27:34 +0300 (EEST) Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-10bec750eedso3543596fac.8 for ; Sun, 03 Jul 2022 17:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=6eJQVsNHvCyjA/OJcq29lNc+P3C3oENctnIbgs8bX7g=; b=UXtFYKBAADj1Aj6iRcdV8GPq0U2QF4/5CouXY5p6VWsIsEkPfoiS07OCZoSjeenST/ 4V01oDez1Rd5eFaupaQPO/qjhD5u/a3wY0aQHF5incNdtdNkQDdISp9P/wLiBOHhGyrl Z7qfXyAxCGzw3XZ/fL4etYtyHtcYJZmE4IvjSZXBXK8Iy9U1OERkvRLcU8OD8b7UWii2 08MZ0mWlQJpFIKqxyuZtqw6gowqdmrcNkg0DLacAKP9ZLYBg+HM2teK7xntnAH2mICSQ 15lvttzYEf4AFs21pD7SMf46H08airvmqYWpnT+mzxtXFpDh6yPwfhFgp1xPTlBgl22X RANw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=6eJQVsNHvCyjA/OJcq29lNc+P3C3oENctnIbgs8bX7g=; b=vQytcDSTEbl9y7p7w4ly3G8oxep4ZHBxWyLjhUcy7lIHtfD/o9E2HLg9clNPPv1WPZ tDq9B5HXLnxVSPRK8anFXFBpPa3dEv1tn0hcygtGp8t+/qJXzpc86O7VPJq8ZhpNfZHk 0njYp2Z5IBCgaKWN35c5OduFWANqqfNiR/vyCbrkSMYZg5fzq9v5R3P1PXg0TpEcuNUV Mpm4Y3WJ4D7QDa3w/i0mK9yqdh43HzJiGvSide2HUwMNtmTlSjieThBm0ZvSKLAC97ue 3OWm9U+iv2lvF5en9guVVuKrPojQW7swSFIjkAyzCzbXLv+9LhWHzw359d7UazjuYCbs DQGA== X-Gm-Message-State: AJIora9ArInzVrj6ChaEpwe5Wp/WExIPCQTonRlvcXRLrf8fEc8tX3Qm RxooleFkJqeIcckk320n7uS7rAs7TYbDYg== X-Google-Smtp-Source: AGRyM1tQJmWvM0KCbkhV/HpX2vkSOUO/gxICq2p/aserttWVCghjvbEGi6rUBDtMtCU1ybK48DZAXQ== X-Received: by 2002:a05:6870:548d:b0:108:6d47:f61c with SMTP id f13-20020a056870548d00b001086d47f61cmr16159656oan.218.1656894452047; Sun, 03 Jul 2022 17:27:32 -0700 (PDT) Received: from [192.168.0.13] ([186.136.131.204]) by smtp.gmail.com with ESMTPSA id b6-20020a056870d1c600b00101bc3380a5sm6099575oac.12.2022.07.03.17.27.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Jul 2022 17:27:30 -0700 (PDT) Message-ID: <038f9809-c563-6f9b-3640-8587b213c9bb@gmail.com> Date: Sun, 3 Jul 2022 21:27:31 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220702222532.9609-1-jamrial@gmail.com> From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avutil/channel_layout: don't error out on truncated strings X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 7/3/2022 7:00 AM, Nicolas George wrote: > Andreas Rheinhardt (12022-07-03): >>> if (!av_bprint_is_complete(bp)) >>> - return AVERROR(ENOMEM); >>> + break; >>> > >> Isn't this actually still against the API? av_channel_layout_describe() >> will not return the correct number of bytes necessary to write the >> string for the channel layout. > > You are both right. > > BPrint-based APIs are not supposed to check for truncation, because > printing into a bounded buffer to determine the necessary size is a > valid use (see AV_BPRINT_SIZE_COUNT_ONLY). > > What is wrong is Michael's original fix: > >>> commit 8154cb7c2ff2afcb1a0842de8c215b7714c814d0 >>> Author: Michael Niedermayer >>> Date: 2022-06-30 00:00:32 +0200 >>> >>> avutil/channel_layout: av_channel_layout_describe_bprint: Check for buffer end >>> >>> Fixes: Timeout printing a billion channels >>> Fixes: 48099/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6754782204788736 >>> >>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >>> Signed-off-by: Michael Niedermayer >>> >>> diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c >>> index 21b70173b7..1887987789 100644 >>> --- a/libavutil/channel_layout.c >>> +++ b/libavutil/channel_layout.c >>> @@ -757,6 +757,10 @@ int av_channel_layout_describe_bprint(const AVChannelLayout *channel_layout, >>> if (channel_layout->order == AV_CHANNEL_ORDER_CUSTOM && > >>> channel_layout->u.map[i].name[0]) > > If the channel count is insanely high, then this will cause invalid > reads. > >>> av_bprintf(bp, "@%s", channel_layout->u.map[i].name); >>> + >>> + if (!av_bprint_is_complete(bp)) >>> + return AVERROR(ENOMEM); >>> + >>> } >>> if (channel_layout->nb_channels) { >>> av_bprintf(bp, ")"); > > Obviously, this fuzzer found a case where a demuxer or a decoder > constructs an invalid channel layout in memory without proper > validation. There is a bug, possibly an security-related one, and this > only hides it from the test suite. The Matroska demuxer could in theory generate a native layout with more than 64 channels where popcnt(mask) != channels, and nothing seems to validate what a demuxer's read_header() callback returns if you just call lavf API functions like target_dem_fuzzer.c seems to do. Maybe: > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > index 73ded761fd..ad7ee390a2 100644 > --- a/libavformat/matroskadec.c > +++ b/libavformat/matroskadec.c > @@ -2950,10 +2950,10 @@ static int matroska_parse_tracks(AVFormatContext *s) > st->codecpar->codec_tag = fourcc; > st->codecpar->sample_rate = track->audio.out_samplerate; > // channel layout may be already set by codec private checks above > - if (st->codecpar->ch_layout.order == AV_CHANNEL_ORDER_NATIVE && > - !st->codecpar->ch_layout.u.mask) > + if (!av_channel_layout_check(&st->codecpar->ch_layout)) { > st->codecpar->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC; > - st->codecpar->ch_layout.nb_channels = track->audio.channels; > + st->codecpar->ch_layout.nb_channels = track->audio.channels; > + } > if (!st->codecpar->bits_per_coded_sample) > st->codecpar->bits_per_coded_sample = track->audio.bitdepth; > if (st->codecpar->codec_id == AV_CODEC_ID_MP3 || is enough to ensure a valid layout is propagated. This assumes parameters set by codec private parsing are correct (only FLAC seem to be present right now, and it is). Assuming i got this right, in this fuzzing sample's case it would still have a billion channels (since that's what track->audio.channels contains, as read from the container), but using the unspec layout, which is technically valid even if nothing will really handle it, and av_channel_layout_describe() will print a small string. Still, i think a check in avformat_open_input() might also be a good idea, especially once (and if) demuxers start propagating custom layouts, where the map array will be allocated. > > The proper fix is to find where the input is improperly validated, and > then revert this change. > > I do not know how to exploit the > "48099/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6754782204788736" > information to reproduce the bug and investigate. Michael can share the sample, but you need to compile tools/target_dem_fuzzer.c to read it. > > Regards, > > > _______________________________________________ > 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". _______________________________________________ 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".