[FFmpeg-devel] patch to disable SMUSH codec from autoselect

[FFmpeg-devel] patch to disable SMUSH codec from autoselect

[Oliver via ffmpeg-devel]

This is a simple patch to mark SMUSH experimental so it doesn't 
autoselect when choosing the codec.  This prevents a malicious file from 
exploiting CVE-2025-59734 when a user isn't explicitly choosing that codec.

I have tested this against Google's reference payload with and without 
this change.

I've never submitted to ffmpeg before, so apologies if I'm in the wrong 
place or missing something.

---
  libavformat/smush.c | 1 +
  1 file changed, 1 insertion(+)
  mode change 100644 => 100755 libavformat/smush.c

diff --git a/libavformat/smush.c b/libavformat/smush.c
old mode 100644
new mode 100755
index d380bfbff1..3389bb630f
--- a/libavformat/smush.c
+++ b/libavformat/smush.c
@@ -256,6 +256,7 @@ static int smush_read_packet(AVFormatContext *ctx, 
AVPacket *pkt)
  const FFInputFormat ff_smush_demuxer = {
      .p.name         = "smush",
      .p.long_name    = NULL_IF_CONFIG_SMALL("LucasArts Smush"),
+    .p.flags        = AVFMT_EXPERIMENTAL,
      .priv_data_size = sizeof(SMUSHContext),
      .read_probe     = smush_read_probe,
      .read_header    = smush_read_header,
--
2.43.0


_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: patch to disable SMUSH codec from autoselect

[Rémi Denis-Courmont via ffmpeg-devel]

Hi,

Experimental means part of an experiment. The SMUSH decoder might have qualified as experimental while it was being implemented (reverse engineered?), but not today.

What it is is unsupported, but the same could be said of, well, essentially every codec in FFmpeg, as per the GPL/LGPL warranty disclaimer. SMUSH is also not formally proven secure, but again, the same could be said of every codecs (or almost) in FFmpeg as of today.

The same argument that FFmpeg should disable game codecs or other "unsupported" was raised on Saturday at VDD. Though those discussions do not bind the FFmpeg project in any way, most people in the room seemed to agree that classifying the hundreds of codecs in such vague, variable and subjective wasn't viable.

In other words, it's up to whoever compiles the software downstream to determine what they want to support and what they don't, IMO, not the FFmpeg project/community.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: patch to disable SMUSH codec from autoselect

[Oliver via ffmpeg-devel]

Thank you for the quick response.

I had intended this as a medium-term fix to the referenced CVE that 
Google found.  In other words, SMUSH is specifically not secure.  This 
seems to be the most straightforward approach.  It will prevent anyone 
using auto-selection of the codec from being the victim of a malicious 
payload while still allowing them to explicitly use SMUSH for 
conversions if desired.

I had actually planned to add a new flag when I saw this mechanism 
already existed for "experimental".  I could add a new flag such as 
"unsafe" or "pending_cve" or such and key off that as well in the same 
place?

Or is it the position of ffmpeg that the SMUSH vulnerability should be 
left in place until a full fix of the codec is made? Your @FFmpeg X 
account made it sound like there would be no attempt to do this.  But if 
one is expected reasonably soon perhaps this is not a useful change anyway.

Best Regards,

Oliver


On 11/4/2025 5:56 PM, Rémi Denis-Courmont wrote:
> Hi,
>
> Experimental means part of an experiment. The SMUSH decoder might have qualified as experimental while it was being implemented (reverse engineered?), but not today.
>
> What it is is unsupported, but the same could be said of, well, essentially every codec in FFmpeg, as per the GPL/LGPL warranty disclaimer. SMUSH is also not formally proven secure, but again, the same could be said of every codecs (or almost) in FFmpeg as of today.
>
> The same argument that FFmpeg should disable game codecs or other "unsupported" was raised on Saturday at VDD. Though those discussions do not bind the FFmpeg project in any way, most people in the room seemed to agree that classifying the hundreds of codecs in such vague, variable and subjective wasn't viable.
>
> In other words, it's up to whoever compiles the software downstream to determine what they want to support and what they don't, IMO, not the FFmpeg project/community.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: patch to disable SMUSH codec from autoselect

[Kieran Kunhya via ffmpeg-devel]

>
> Or is it the position of ffmpeg that the SMUSH vulnerability should be
> left in place until a full fix of the codec is made?
>

The issue was fixed a long time ago.
Also please don't top post.

Kieran

>
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org