Re: [FFmpeg-devel] [PATCH 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

2024-04-01 Thread Michael Niedermayer 
On Mon, Apr 01, 2024 at 11:35:56PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: memleak
> > Fixes: 
> > 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/demux_utils.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
> > index 86f551245be..96e6e20d1ec 100644
> > --- a/libavformat/demux_utils.c
> > +++ b/libavformat/demux_utils.c
> > @@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream 
> > *st0, AVIOContext *pb,
> >  if (!st && !(st = avformat_new_stream(s, NULL)))
> >  return AVERROR(ENOMEM);
> >  pkt = >attached_pic;
> > +av_packet_unref(pkt);
> >  if (buf) {
> >  av_assert1(*buf);
> > -av_packet_unref(pkt);
> >  pkt->buf  = *buf;
> >  pkt->data = (*buf)->data;
> >  pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;
> 
> This seems to be from the ff_add_attached_pic() call in
> mov_read_chapters() with the referenced stream having been created in
> mov_read_covr(). The latter does not set a proper id -- it just takes
> what avformat_new_stream() sets as id on every new stream (namely zero).
> So it makes no real sense to compare it to the ids contained in
> chapter_tracks (can really every track be reinterpreted as chapter
> track?). But I am no mov/mp4 expert.
> Anyway, does the following fix it?
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 7bdeeb99f9..51d97296f1 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -8820,7 +8820,7 @@ static void mov_read_chapters(AVFormatContext *s)
> 
>  if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
>  st->disposition |= AV_DISPOSITION_ATTACHED_PIC |
> AV_DISPOSITION_TIMED_THUMBNAILS;
> -if (sti->nb_index_entries) {
> +if (!st->attached_pic.data && sti->nb_index_entries) {
>  // Retrieve the first frame, if possible
>  AVIndexEntry *sample = >index_entries[0];
>  if (avio_seek(sc->pb, sample->pos, SEEK_SET) !=
> sample->pos) {
> s

Yes, this fixes it too, please apply and backport as needed

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

2024-04-01 Thread Andreas Rheinhardt 
Michael Niedermayer:
> Fixes: memleak
> Fixes: 
> 67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/demux_utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
> index 86f551245be..96e6e20d1ec 100644
> --- a/libavformat/demux_utils.c
> +++ b/libavformat/demux_utils.c
> @@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream 
> *st0, AVIOContext *pb,
>  if (!st && !(st = avformat_new_stream(s, NULL)))
>  return AVERROR(ENOMEM);
>  pkt = >attached_pic;
> +av_packet_unref(pkt);
>  if (buf) {
>  av_assert1(*buf);
> -av_packet_unref(pkt);
>  pkt->buf  = *buf;
>  pkt->data = (*buf)->data;
>  pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;

This seems to be from the ff_add_attached_pic() call in
mov_read_chapters() with the referenced stream having been created in
mov_read_covr(). The latter does not set a proper id -- it just takes
what avformat_new_stream() sets as id on every new stream (namely zero).
So it makes no real sense to compare it to the ids contained in
chapter_tracks (can really every track be reinterpreted as chapter
track?). But I am no mov/mp4 expert.
Anyway, does the following fix it?

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7bdeeb99f9..51d97296f1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8820,7 +8820,7 @@ static void mov_read_chapters(AVFormatContext *s)

 if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
 st->disposition |= AV_DISPOSITION_ATTACHED_PIC |
AV_DISPOSITION_TIMED_THUMBNAILS;
-if (sti->nb_index_entries) {
+if (!st->attached_pic.data && sti->nb_index_entries) {
 // Retrieve the first frame, if possible
 AVIndexEntry *sample = >index_entries[0];
 if (avio_seek(sc->pb, sample->pos, SEEK_SET) !=
sample->pos) {
s

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/6] avformat/demux_utils: Avoid leaking the packet in ff_add_attached_pic()

2024-04-01 Thread Michael Niedermayer 
Fixes: memleak
Fixes: 
67714/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5671570999476224

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/demux_utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/demux_utils.c b/libavformat/demux_utils.c
index 86f551245be..96e6e20d1ec 100644
--- a/libavformat/demux_utils.c
+++ b/libavformat/demux_utils.c
@@ -123,9 +123,9 @@ int ff_add_attached_pic(AVFormatContext *s, AVStream *st0, 
AVIOContext *pb,
 if (!st && !(st = avformat_new_stream(s, NULL)))
 return AVERROR(ENOMEM);
 pkt = >attached_pic;
+av_packet_unref(pkt);
 if (buf) {
 av_assert1(*buf);
-av_packet_unref(pkt);
 pkt->buf  = *buf;
 pkt->data = (*buf)->data;
 pkt->size = (*buf)->size - AV_INPUT_BUFFER_PADDING_SIZE;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".