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 8B1DF4067B for ; Fri, 26 Aug 2022 15:44:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9E02E68B9D2; Fri, 26 Aug 2022 18:44:54 +0300 (EEST) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2C7F468B559 for ; Fri, 26 Aug 2022 18:44:48 +0300 (EEST) Received: by mail-pj1-f44.google.com with SMTP id w88-20020a17090a6be100b001fbb0f0b013so2149834pjj.5 for ; Fri, 26 Aug 2022 08:44:48 -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=IrtfNmwH0dg7wIg3nBRJHlm+FVKyGPbd6cUR/Ob3Ajw=; b=DcGCLWVtUO5g66L1pKNa1NjLQ+Mees6fkJ8gz6t/XTfqFIyc96RLmw+kcmEvTCI5JC mGb/B96vcFJkKUOw4GI47ZMqHgaSsenBxxS/WRgvkDJc88MOpJT+fUR96aNqQZef0NcV bk/TDiVk9hcpPX1tba71p/t4PWDTrdc02eDWiP1rxqhgF2kygwUwxsPs0gQ6N1rncVxR LaJmxKgZyGWnfi4nZDjAgVli8VplLSP/2Htd4cSUv43PKzjrZAZ4MEt3DHvgRj+R+Rlj 5xYr7LLJ3grEfx66Q/DgRo1dVioucR4WFU9HD/lhGteS5BoIZV8WwA+wFh4M/VqQxe+P mCRQ== 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=IrtfNmwH0dg7wIg3nBRJHlm+FVKyGPbd6cUR/Ob3Ajw=; b=gtEtfOHk6Fbw9Mg3HqeReVvQp/mc5YkyHGE+WhqXyKwF3B4pLBzncSZ37nTM7YSwyi +9RbE6Pi3fifyJa5BQKViJqIZDcpmfldZ8q4mWKPU1hyN3oqf0O1P0REMDq+N6o5Zdhx N0/JMD6DjUgJkjbN92rfFBQrKOY5/5qbY6uLXBr4GxwdR3LiofK3Xf47v6YCJl9pJ9TC jkKzs3abXVG/2zHSf9qtaE1PFYemV+Zgb6kKUqxhbyBxf0mJpGpqY7U9JPUlaU8ili7C Q7ur5TObIt6A2gSjToQL7Dcb8wLsoNXbUxqHEZ9D6GC+NIu/PLKLs6RpRYyzbrjgB0I6 e/fQ== X-Gm-Message-State: ACgBeo39sfGWa8zYwf0Q6+YcPZzjI600516k96+KZ2g2rVz7M1eY6tYI Vg4AIZ7Lb7Ue5h/9SlsxD6hSNTJuIuef/A== X-Google-Smtp-Source: AA6agR51o8oFIjVS5iCNF+TMl1jbQlrH8eicawZt6Ccls4gyO9yP+erLyHxNceJbiqMZLn4c2DJaiQ== X-Received: by 2002:a17:90b:38cf:b0:1fb:783c:e0f with SMTP id nn15-20020a17090b38cf00b001fb783c0e0fmr5033028pjb.204.1661528685635; Fri, 26 Aug 2022 08:44:45 -0700 (PDT) Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com. [209.85.215.173]) by smtp.gmail.com with ESMTPSA id k3-20020aa79d03000000b00537d4a3aec9sm1165899pfp.104.2022.08.26.08.44.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 08:44:44 -0700 (PDT) Received: by mail-pg1-f173.google.com with SMTP id v4so1711308pgi.10 for ; Fri, 26 Aug 2022 08:44:44 -0700 (PDT) X-Received: by 2002:a05:6a00:4207:b0:537:ab7a:11b4 with SMTP id cd7-20020a056a00420700b00537ab7a11b4mr4402450pfb.49.1661528683987; Fri, 26 Aug 2022 08:44:43 -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 08:44:31 -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 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? > (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. 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? > > > 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".