[FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Pavel Koshevoy]

Fixes 'ffprobe 1_poc.mp4' segfault introduced with
commit 0021484d05f9b0f032fa319399de6e24eea0c04f

codec_close should not assume that the codec_id did not change.
---
 libavformat/demux.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavformat/demux.c b/libavformat/demux.c
index ecd4f40da9..3749ab67a3 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1292,9 +1292,15 @@ static int codec_close(FFStream *sti)
 {
     AVCodecContext *avctx_new = NULL;
     AVCodecParameters *par_tmp = NULL;
+    const AVCodec *new_codec = NULL;
     int ret;
 
-    avctx_new = avcodec_alloc_context3(sti->avctx->codec);
+    new_codec =
+      (sti->avctx->codec_id != sti->pub.codecpar->codec_id) ?
+      avcodec_find_decoder(sti->pub.codecpar->codec_id) :
+      sti->avctx->codec;
+
+    avctx_new = avcodec_alloc_context3(new_codec);
     if (!avctx_new) {
         ret = AVERROR(ENOMEM);
         goto fail;
-- 
2.43.0

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2196 bytes --]

On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> 
> codec_close should not assume that the codec_id did not change.
> ---
>  libavformat/demux.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index ecd4f40da9..3749ab67a3 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -1292,9 +1292,15 @@ static int codec_close(FFStream *sti)
>  {
>      AVCodecContext *avctx_new = NULL;
>      AVCodecParameters *par_tmp = NULL;
> +    const AVCodec *new_codec = NULL;
>      int ret;
>  
> -    avctx_new = avcodec_alloc_context3(sti->avctx->codec);
> +    new_codec =
> +      (sti->avctx->codec_id != sti->pub.codecpar->codec_id) ?
> +      avcodec_find_decoder(sti->pub.codecpar->codec_id) :
> +      sti->avctx->codec;
> +
> +    avctx_new = avcodec_alloc_context3(new_codec);
>      if (!avctx_new) {
>          ret = AVERROR(ENOMEM);
>          goto fail;

This is not about request_probe
but about the mpegts demuxer randomly changeing codec id midstream

I belive the patch should be reverted that causes this. I dont think
applications expect such mid stream changes either

I hope andreas can take a look and correct me if iam missing something
but it looks a bit sketchy to me

If a codec changes mid stream i belive a new AVStream
should be created. It could be a audio stream switches to video
or data or subtitle.

If any stream as detected initially can become any other type later
this complicates user applications and filter graphs
Also the management of AVPackets is probably rather non trivial
if the stream_index is not enough to identify which decoder it belongs to

thx

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

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Pavel Koshevoy]

On Tue, Jun 10, 2025, 07:39 Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> > Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> > commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> >
> > codec_close should not assume that the codec_id did not change.
> > ---
> >  libavformat/demux.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/demux.c b/libavformat/demux.c
> > index ecd4f40da9..3749ab67a3 100644
> > --- a/libavformat/demux.c
> > +++ b/libavformat/demux.c
> > @@ -1292,9 +1292,15 @@ static int codec_close(FFStream *sti)
> >  {
> >      AVCodecContext *avctx_new = NULL;
> >      AVCodecParameters *par_tmp = NULL;
> > +    const AVCodec *new_codec = NULL;
> >      int ret;
> >
> > -    avctx_new = avcodec_alloc_context3(sti->avctx->codec);
> > +    new_codec =
> > +      (sti->avctx->codec_id != sti->pub.codecpar->codec_id) ?
> > +      avcodec_find_decoder(sti->pub.codecpar->codec_id) :
> > +      sti->avctx->codec;
> > +
> > +    avctx_new = avcodec_alloc_context3(new_codec);
> >      if (!avctx_new) {
> >          ret = AVERROR(ENOMEM);
> >          goto fail;
>
> This is not about request_probe
> but about the mpegts demuxer randomly changeing codec id midstream
>


I have several real (not crafted like 1_poc.mp4 is) .ts files where codec
changes from mpeg2video to hevc, from mpeg2audio to eac3 -- while remaining
on the same PIDs.  I also have .ts files where codec switches between
mpeg2video and h264.  VLC was able to play such files, but my ffmpeg based
player (apprenticevideo) could not even see that the codecs changed prior
to 0021484d05f9b0f032fa319399de6e24eea0c04f.  Reverting isn't really an
option for me, not unless there is a better solution presented.

As I am primarily a public ffmpeg API user -- I am well out of my depth
when it comes to making non-trivial changes to ffmpegs internals.





> I belive the patch should be reverted that causes this. I dont think
> applications expect such mid stream changes either
>

I have 2 applications that expect such behavior.


> I hope andreas can take a look and correct me if iam missing something
> but it looks a bit sketchy to me
>
> If a codec changes mid stream i belive a new AVStream
> should be created. It could be a audio stream switches to video
> or data or subtitle.
>

In my player I support video/audio track selection.  MPEG-TS tracks are
associated with a PID.  If the PID did not change but the codec changed --
it's still the same track, and I axpect my player to play it out -- I don't
expect the user to go search for some new track because the codec changed.


> If any stream as detected initially can become any other type later
> this complicates user applications and filter graphs
>

I think this is mostly a issue with the crafted 1_poc.mp4 file.


Also the management of AVPackets is probably rather non trivial
> if the stream_index is not enough to identify which decoder it belongs to
>

In my player I monitor AVCodecParameters for changes, and I attach a
shared_ptr to AVCodecParameters to each packet, so when time comes to
decode a packet I can check if its codecpar matches the current decoder,
and open a new decoder if the codec has changed.  It's not trivial, but not
complicated either.


> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Old school: Use the lowest level language in which you can solve the
> problem
>             conveniently.
> New school: Use the highest level language in which the latest
> supercomputer
>             can solve the problem without the user falling asleep waiting.
> _______________________________________________
> 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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3387 bytes --]

Hi Pavel

On Tue, Jun 10, 2025 at 08:42:08AM -0600, Pavel Koshevoy wrote:
> On Tue, Jun 10, 2025, 07:39 Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> > > Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> > > commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> > >
> > > codec_close should not assume that the codec_id did not change.
> > > ---
> > >  libavformat/demux.c | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/demux.c b/libavformat/demux.c
> > > index ecd4f40da9..3749ab67a3 100644
> > > --- a/libavformat/demux.c
> > > +++ b/libavformat/demux.c
> > > @@ -1292,9 +1292,15 @@ static int codec_close(FFStream *sti)
> > >  {
> > >      AVCodecContext *avctx_new = NULL;
> > >      AVCodecParameters *par_tmp = NULL;
> > > +    const AVCodec *new_codec = NULL;
> > >      int ret;
> > >
> > > -    avctx_new = avcodec_alloc_context3(sti->avctx->codec);
> > > +    new_codec =
> > > +      (sti->avctx->codec_id != sti->pub.codecpar->codec_id) ?
> > > +      avcodec_find_decoder(sti->pub.codecpar->codec_id) :
> > > +      sti->avctx->codec;
> > > +
> > > +    avctx_new = avcodec_alloc_context3(new_codec);
> > >      if (!avctx_new) {
> > >          ret = AVERROR(ENOMEM);
> > >          goto fail;
> >
> > This is not about request_probe
> > but about the mpegts demuxer randomly changeing codec id midstream
> >
> 
> 
> I have several real (not crafted like 1_poc.mp4 is) .ts files where codec
> changes from mpeg2video to hevc, from mpeg2audio to eac3 -- while remaining
> on the same PIDs.  I also have .ts files where codec switches between
> mpeg2video and h264.  VLC was able to play such files, but my ffmpeg based
> player (apprenticevideo) could not even see that the codecs changed prior
> to 0021484d05f9b0f032fa319399de6e24eea0c04f.

do these work ?
(work here means the result is a complete file with all frames from the input
 and is playable and seekable)
./ffmpeg -i input.ts -codec copy output.ts
./ffmpeg -i input.ts -codec copy output.mp4
./ffmpeg -i input.ts -vcodec libx264 -acodec libopus output.mkv


> Reverting isn't really an
> option for me, not unless there is a better solution presented.

is adding an exploitable security issue an option for you ?

If people want to keep this, it should be behind a flag and
disabled by default.

Its not enough to fix our code that crashes, other applications
similarly wont expect such id and type changes mid stream


> 
> As I am primarily a public ffmpeg API user -- I am well out of my depth
> when it comes to making non-trivial changes to ffmpegs internals.

Thats ok, but you applied this change to ffmpeg internals, and here
you say "I am well out of my depth when it comes to making non-trivial changes to ffmpegs internals."

Did someone review this ?

commit 0021484d05f9b0f032fa319399de6e24eea0c04f
Author:     Pavel Koshevoy <pkoshevoy@gmail.com>
AuthorDate: Sun May 18 08:57:31 2025 -0600
Commit:     Pavel Koshevoy <pkoshevoy@gmail.com>
CommitDate: Sun May 18 08:57:31 2025 -0600


thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Pavel Koshevoy]

On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi Pavel
>
> On Tue, Jun 10, 2025 at 08:42:08AM -0600, Pavel Koshevoy wrote:
> > On Tue, Jun 10, 2025, 07:39 Michael Niedermayer <michael@niedermayer.cc>
> > wrote:
> >
> > > On Mon, Jun 09, 2025 at 09:45:28PM -0600, Pavel Koshevoy wrote:
> > > > Fixes 'ffprobe 1_poc.mp4' segfault introduced with
> > > > commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> > > >
> > > > codec_close should not assume that the codec_id did not change.
> > > > ---
> > > >  libavformat/demux.c | 8 +++++++-
> > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavformat/demux.c b/libavformat/demux.c
> > > > index ecd4f40da9..3749ab67a3 100644
> > > > --- a/libavformat/demux.c
> > > > +++ b/libavformat/demux.c
> > > > @@ -1292,9 +1292,15 @@ static int codec_close(FFStream *sti)
> > > >  {
> > > >      AVCodecContext *avctx_new = NULL;
> > > >      AVCodecParameters *par_tmp = NULL;
> > > > +    const AVCodec *new_codec = NULL;
> > > >      int ret;
> > > >
> > > > -    avctx_new = avcodec_alloc_context3(sti->avctx->codec);
> > > > +    new_codec =
> > > > +      (sti->avctx->codec_id != sti->pub.codecpar->codec_id) ?
> > > > +      avcodec_find_decoder(sti->pub.codecpar->codec_id) :
> > > > +      sti->avctx->codec;
> > > > +
> > > > +    avctx_new = avcodec_alloc_context3(new_codec);
> > > >      if (!avctx_new) {
> > > >          ret = AVERROR(ENOMEM);
> > > >          goto fail;
> > >
> > > This is not about request_probe
> > > but about the mpegts demuxer randomly changeing codec id midstream
> > >
> >
> >
> > I have several real (not crafted like 1_poc.mp4 is) .ts files where codec
> > changes from mpeg2video to hevc, from mpeg2audio to eac3 -- while
> remaining
> > on the same PIDs.  I also have .ts files where codec switches between
> > mpeg2video and h264.  VLC was able to play such files, but my ffmpeg
> based
> > player (apprenticevideo) could not even see that the codecs changed prior
> > to 0021484d05f9b0f032fa319399de6e24eea0c04f.
>
> do these work ?
> (work here means the result is a complete file with all frames from the
> input
>  and is playable and seekable)
> ./ffmpeg -i input.ts -codec copy output.ts
> ./ffmpeg -i input.ts -codec copy output.mp4
> ./ffmpeg -i input.ts -vcodec libx264 -acodec libopus output.mkv
>

not really relevant because if they don't work -- it's a defect in the
command line tool, not the demuxer.
I need the libavformat API to work with mpeg-ts data I have, I don't
actually care if ffprobe/ffplay/ffmpeg can handle these files ... they
couldn't handle them before and they still can't, but I'm not an fftools
maintainer so I don't think I'll be taking on a 3rd job to fix fftools as
well.



>
> > Reverting isn't really an
> > option for me, not unless there is a better solution presented.
>
> is adding an exploitable security issue an option for you ?
>

I'm not a security expert, but IIRC the patch I've posted here fixes the
segfault you are referring to?



>
> If people want to keep this, it should be behind a flag and
> disabled by default.
>
> Its not enough to fix our code that crashes, other applications
> similarly wont expect such id and type changes mid stream
>

If mpeg-ts allows the codecs to change at any time -- it's a bug in the
application if it doesn't support that.



>
>
> >
> > As I am primarily a public ffmpeg API user -- I am well out of my depth
> > when it comes to making non-trivial changes to ffmpegs internals.
>
> Thats ok, but you applied this change to ffmpeg internals, and here
> you say "I am well out of my depth when it comes to making non-trivial
> changes to ffmpegs internals."
>
> Did someone review this ?
>

No, it was ignored for weeks.



>
> commit 0021484d05f9b0f032fa319399de6e24eea0c04f
> Author:     Pavel Koshevoy <pkoshevoy@gmail.com>
> AuthorDate: Sun May 18 08:57:31 2025 -0600
> Commit:     Pavel Koshevoy <pkoshevoy@gmail.com>
> CommitDate: Sun May 18 08:57:31 2025 -0600
>
>
> thx
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The greatest way to live with honor in this world is to be what we pretend
> to be. -- Socrates
> _______________________________________________
> 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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Pavel Koshevoy]

On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi Pavel
>
> <snip>

>
> is adding an exploitable security issue an option for you ?
>
>
^ that's inflammatory, I have never had any intention of introducing a
security vulnerability.


If people want to keep this, it should be behind a flag and
> disabled by default.


I am not familiar with such flags ... are you suggesting a compile-time
flag, or a run-time flag?
A runtime flag would be preferable, because that would save me from having
to cross-compile win64 ffmpeg libs myself.


Its not enough to fix our code that crashes, other applications
> similarly wont expect such id and type changes mid stream


IDK how likely a media type change is outside the 1_poc.mp4.  The sample
files I have don't do that.
I can provide a 61MB clip of one such file, just a few seconds of SDR mpeg2
video/audio slate followed by a few seconds of HDR10 hevc video and eac3
audio... in case someone wants to work on making fftools support this.

    Pavel.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Nicolas George]

Pavel Koshevoy (HE12025-06-10):
> ^ that's inflammatory

No, that is just sarcastic.

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Pavel Koshevoy]

On Tue, Jun 10, 2025 at 11:31 AM Nicolas George <george@nsup.org> wrote:

> Pavel Koshevoy (HE12025-06-10):
> > ^ that's inflammatory
>
> No, that is just sarcastic.
>
>

it managed to ruin my morning ... no matter what you call it.

Pavel.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1926 bytes --]

Hi Pavel

On Tue, Jun 10, 2025 at 11:27:37AM -0600, Pavel Koshevoy wrote:
> On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <michael@niedermayer.cc>
[...]

> I have never had any intention of introducing a
> security vulnerability.

do you agree that the patch should be reverted ?
(and also the 2 backports of it)


> If people want to keep this, it should be behind a flag and
> > disabled by default.
> 
> 
> I am not familiar with such flags ... are you suggesting a compile-time
> flag, or a run-time flag?
> A runtime flag would be preferable, because that would save me from having
> to cross-compile win64 ffmpeg libs myself.

runtime


> 
> 
> Its not enough to fix our code that crashes, other applications
> > similarly wont expect such id and type changes mid stream
> 
> 
> IDK how likely a media type change is outside the 1_poc.mp4.

100% likelyness an exploit of this will use it


> The sample
> files I have don't do that.

Your sample files are not exploits i assume. So obviously
they dont


> I can provide a 61MB clip of one such file, just a few seconds of SDR mpeg2
> video/audio slate followed by a few seconds of HDR10 hevc video and eac3
> audio... in case someone wants to work on making fftools support this.

This file certainly is valuable and should be added to samples.ffmpeg.org

BUT this security issue needs to be fixed, regardless of
anyone adding support for such samples

I dont think backporting midstream codec_id/type changes is a good
idea btw.

IMHO this should all be reverted (its a small 3 line patch)
and then again start from scratch with review, testing, fuzzing, and
runtime flag.

PS: The researcher also wants a CVE# for this issue.

thx

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

What is money laundering? Its paying someone and not telling the government.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Pavel Koshevoy]

On Tue, Jun 10, 2025 at 4:11 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi Pavel
>
> On Tue, Jun 10, 2025 at 11:27:37AM -0600, Pavel Koshevoy wrote:
> > On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <
> michael@niedermayer.cc>
> [...]
>
> > I have never had any intention of introducing a
> > security vulnerability.
>
> do you agree that the patch should be reverted ?
> (and also the 2 backports of it)
>

No, since I already provided a fix -- I would cherry-pick it to the
release/6.1 and release/7.1 as well, but you do as you wish.



>
>
> > If people want to keep this, it should be behind a flag and
> > > disabled by default.
> >
> >
> > I am not familiar with such flags ... are you suggesting a compile-time
> > flag, or a run-time flag?
> > A runtime flag would be preferable, because that would save me from
> having
> > to cross-compile win64 ffmpeg libs myself.
>
> runtime
>
>
> >
> >
> > Its not enough to fix our code that crashes, other applications
> > > similarly wont expect such id and type changes mid stream
> >
> >
> > IDK how likely a media type change is outside the 1_poc.mp4.
>
> 100% likelyness an exploit of this will use it
>
>
> > The sample
> > files I have don't do that.
>
> Your sample files are not exploits i assume. So obviously
> they dont
>
>
> > I can provide a 61MB clip of one such file, just a few seconds of SDR
> mpeg2
> > video/audio slate followed by a few seconds of HDR10 hevc video and eac3
> > audio... in case someone wants to work on making fftools support this.
>
> This file certainly is valuable and should be added to samples.ffmpeg.org
>
> BUT this security issue needs to be fixed, regardless of
> anyone adding support for such samples
>
> I dont think backporting midstream codec_id/type changes is a good
> idea btw.
>
> IMHO this should all be reverted (its a small 3 line patch)
> and then again start from scratch with review, testing, fuzzing, and
> runtime flag.
>
> PS: The researcher also wants a CVE# for this issue.
>

IDK what this means.



>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> What is money laundering? Its paying someone and not telling the
> government.
> _______________________________________________
> 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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1020 bytes --]

Hi Pavel

On Tue, Jun 10, 2025 at 05:36:14PM -0600, Pavel Koshevoy wrote:
> On Tue, Jun 10, 2025 at 4:11 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > Hi Pavel
> >
> > On Tue, Jun 10, 2025 at 11:27:37AM -0600, Pavel Koshevoy wrote:
> > > On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <
> > michael@niedermayer.cc>
> > [...]
> >
> > > I have never had any intention of introducing a
> > > security vulnerability.
> >
> > do you agree that the patch should be reverted ?
> > (and also the 2 backports of it)
> >

[...]

> but you do as you wish.

good that we agree on the release branches
ill locally revert it in both release branches
will be part of the next set of cherry picks i push for these branches

will reply to the rest of the message seperately

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".

Re: [FFmpeg-devel] [PATCH] avformat/demux: Fix segfault due to avcodec_open2 failure (v2)

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]

Hi Pavel

On Tue, Jun 10, 2025 at 05:36:14PM -0600, Pavel Koshevoy wrote:
> On Tue, Jun 10, 2025 at 4:11 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > Hi Pavel
> >
> > On Tue, Jun 10, 2025 at 11:27:37AM -0600, Pavel Koshevoy wrote:
> > > On Tue, Jun 10, 2025 at 9:29 AM Michael Niedermayer <
> > michael@niedermayer.cc>
> > [...]
> >
> > > I have never had any intention of introducing a
> > > security vulnerability.
> >
> > do you agree that the patch should be reverted ?
> > (and also the 2 backports of it)
> >
> 
> No, since I already provided a fix

To clarify, iam not against your fix, (if its reviewed)
my concern is that this fix is not sufficent to add support
for changing codec_id and codec_type at random points mid stream


[...]

> >
> > PS: The researcher also wants a CVE# for this issue.
> >
> 
> IDK what this means.

More eyes looking at this

thx

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".