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 E3AF0432A9 for ; Fri, 26 Aug 2022 16:06:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C702068B9F3; Fri, 26 Aug 2022 19:06:48 +0300 (EEST) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DDD4D68B680 for ; Fri, 26 Aug 2022 19:06:42 +0300 (EEST) Received: by mail-pg1-f171.google.com with SMTP id c24so1756487pgg.11 for ; Fri, 26 Aug 2022 09:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandflow-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc; bh=pvthbs2U6V5E4E4gSiOF1Nt4urg71HIPpSReUUWOgLw=; b=Ax/iDew3Wzd93hRfpNK/1lCrEBqzip5f3UILMi60OQMcD1Bt86aVijdLtEQ6iIzWH2 Mdl6cCKtYZwUBxI3zHmEej4uCZ4njeehTYRq0y8o+PikEhIEvNQnuKAUIP910WEDvtT2 3Wu35HbJAHxr45e+BX5IydTJ7Jlr9Br7J2nWhh1EdBZKf66WdbnwKK6Fzy6qOLUZ30Ud V81lCSZN/lQX5u+i8hKQxLYuht7QJzJTN6MIblIVq5NGd6Q6JDKQ6L1fpBk6s2C/2my3 cYn2GWMmrPfsEILjBQuZQeOt0ugru23MzOGRm1LNjR3R6A2cEbcaOafhxoUDR+7izV3t hq7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc; bh=pvthbs2U6V5E4E4gSiOF1Nt4urg71HIPpSReUUWOgLw=; b=k8fVuyRy09ZMbW3gITHTBJAhISnmeeC4nasDdEs99UPQ++jFXVHFHYKyx3QBCKGkW/ IEqjIuZWRYEd0gLbV4+2DmDKWZnZ3OUkFRlbvRFxoIS/PwddLt2SJAytwJIsRz6x5K9y 1AY/yAvS21NP/u8p5Mj7u6TkXsBxUM4shm77SnYUU4C+8Sjh47xWD7J6zQ9YsvPH/A4W wT4pFRmOlYboEfXWDVXr5zS3KiFivw2eeLhf0iKFiQWucdnSvrKynXLTw63i6TrfC96x ozzRUcOxLPkqnD4/uPegiDn60bt/6pGFRs3ryIolUV+d++5AG4YUB4P+a/SVQkpMl4Zd piBQ== X-Gm-Message-State: ACgBeo3/+0JWfbm9IDuZdikxacPWbt9+C/ap9Tn6SF/vqAX8SFKPex+T 3KOdKU/KuwxsRwdx/NZKSX8MTrTPWKNFEg== X-Google-Smtp-Source: AA6agR4DXpno/BLZibzKSQWnwQqlDWxsvDJ9HLLesi+MZlLSft0jF4Ev4WQelm2KaDrhdLj+lNdgng== X-Received: by 2002:a63:904c:0:b0:42b:404a:cc50 with SMTP id a73-20020a63904c000000b0042b404acc50mr3786404pge.559.1661530000756; Fri, 26 Aug 2022 09:06:40 -0700 (PDT) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com. [209.85.216.41]) by smtp.gmail.com with ESMTPSA id i15-20020a170902c94f00b00172925f3c79sm1821750pla.153.2022.08.26.09.06.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 09:06:40 -0700 (PDT) Received: by mail-pj1-f41.google.com with SMTP id r14-20020a17090a4dce00b001faa76931beso8511515pjl.1 for ; Fri, 26 Aug 2022 09:06:39 -0700 (PDT) X-Received: by 2002:a17:902:7615:b0:172:c28a:5506 with SMTP id k21-20020a170902761500b00172c28a5506mr4310365pll.8.1661529999339; Fri, 26 Aug 2022 09:06:39 -0700 (PDT) MIME-Version: 1.0 References: <20220826064456.92895-1-lq@chinaffmpeg.org> In-Reply-To: From: Pierre-Anthony Lemieux Date: Fri, 26 Aug 2022 09:06:27 -0700 X-Gmail-Original-Message-ID: Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/imfdec: check track valid before use it 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, Aug 26, 2022 at 9:01 AM Andreas Rheinhardt wrote: > > Pierre-Anthony Lemieux: > > On Fri, Aug 26, 2022 at 1:37 AM Andreas Rheinhardt > > wrote: > >> > >> Steven Liu: > >>> fix CID: 1512414 > >>> And return AVERROR_INVALIDDATA when get_next_track_with_minimum_timestamp > >>> incorrect in imf_read_packet; > >>> > >>> Signed-off-by: Steven Liu > >>> --- > >>> libavformat/imfdec.c | 7 +++++-- > >>> 1 file changed, 5 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > >>> index 5bbe7a53f8..08f342bc1a 100644 > >>> --- a/libavformat/imfdec.c > >>> +++ b/libavformat/imfdec.c > >>> @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx *get_next_track_with_minimum_timestamp(AVForma > >>> } > >>> } > >>> > >>> - av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: %lf / %lf)\n", > >>> - track->index, av_q2d(track->current_timestamp), av_q2d(minimum_timestamp)); > >>> + if (track) > >>> + av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: %lf / %lf)\n", > >>> + track->index, av_q2d(track->current_timestamp), av_q2d(minimum_timestamp)); > >> > >> Coverity actually complained about track being uninitialized, which this > >> patch does not address. And the reason it does this is that it doesn't > >> understand the algorithm: track will always be initialized in the first > >> iteration of the loop. > > > > Is it possible to tell coverity that c->track_count > 0 is a > > pre-condition, or should we modify the loop/algorithm? > > > > The typical way to do this is to add an av_assert1 or av_assert2; > but this must only be done if it is indeed ensured that the assert will > not be triggered. > > >> (If there is a first iteration of the loop -- is > >> this actually guaranteed? A file without tracks seems to be pretty useless.) > > > > imfdec currently assumes that (a) imf_read_packet() is not called if > > there are no streams/tracks and (b) a track will always be found. > > > > (b) will be true for a conformant IMF Composition, but I am not sure > > it can always be true for a malformed one. > > > > Can't we make it true by adding the relevant checks to read_header? Yes. > > > I think imf_read_packet() can probably be hardened. Perhaps do this as > > a patch separately from addressing the coverity issue? > > > >> FYI: In Coverity's analysis there are loop iterations, but it just > >> assumed that track is not initialized in the loop (which boils down to > >> saying that it presumed the tracks' current_timestamp to be invalid > >> (denominator 0). I hope this can't happen. > >> (There is btw another issue: The initialization of minimum_timestamp > >> presumes that int are 32bit which need not be true.) > > > > INT32_MAX -> INT_MAX should fix this right? > > > > Yes. > > >> > >>> return track; > >>> } > >>> > >>> @@ -760,6 +761,8 @@ static int imf_read_packet(AVFormatContext *s, AVPacket *pkt) > >>> AVRational next_timestamp; > >>> > >>> track = get_next_track_with_minimum_timestamp(s); > >>> + if (!track) > >>> + return AVERROR_INVALIDDATA; > >>> > >>> ret = get_resource_context_for_timestamp(s, track, &resource); > >>> if (ret) > >> > >> _______________________________________________ > >> 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". > > _______________________________________________ > 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".