From: "Martin Storsjö" <martin@martin.st>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] rtmpproto: Avoid rare crashes in the fail: codepath in rtmp_open
Date: Tue, 28 Jan 2025 10:50:58 +0200 (EET)
Message-ID: <e89d06c-847c-72f-28e-a956a45e44a5@martin.st> (raw)
In-Reply-To: <20250123111927.68968-1-martin@martin.st>
On Thu, 23 Jan 2025, Martin Storsjö wrote:
> When running the cleanup in rtmp_close on failures in rtmp_open,
> we can in rare cases end up using rt->playpath, assuming that it
> is still set.
>
> The crash could happen if we hit the fail codepath in rtmp_open
> while publishing (rt->is_input == 0) with rt->state set to
> a value > STATE_FCPUBLISH.
>
> This would normally not happen while publishing; either we have
> an error (and rt->state <= STATE_FCPUBLISH) or we reach
> rt->state = STATE_PUBLISHING, and then we also return successfully
> from rtmp_open.
>
> The unexpected combination of states could happen if the server
> responds with e.g. "NetStream.Play.Stop" while expecting
> "NetStream.Publish.Start"; this sets rt->state to STATE_STOPPED,
> which also fulfills the condition "> STATE_FCPUBLISH".
>
> We don't need to free the rt->playpath/tcurl/flashver strings here;
> they're handled via AVOption, and thus are freed automatically when
> the protocol instance is freed (that's why they aren't freed
> manually within the rtmp_close function either).
>
> We also don't need to free the AVDictionary with options; it's
> owned by the caller.
>
> A smaller fix would be to just call rtmp_close before freeing
> the strings and dictionary, but as we don't need to free them
> at all, let's remove that redundant code.
> ---
> libavformat/rtmpproto.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> index a34020b092..4095ae9421 100644
> --- a/libavformat/rtmpproto.c
> +++ b/libavformat/rtmpproto.c
> @@ -2925,10 +2925,6 @@ reconnect:
> return 0;
>
> fail:
> - av_freep(&rt->playpath);
> - av_freep(&rt->tcurl);
> - av_freep(&rt->flashver);
> - av_dict_free(opts);
> rtmp_close(s);
> return ret;
> }
> --
> 2.39.5 (Apple Git-154)
Will push soon.
// Martin
_______________________________________________
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".
next prev parent reply other threads:[~2025-01-28 8:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 11:19 Martin Storsjö
2025-01-28 8:50 ` Martin Storsjö [this message]
2025-01-28 17:59 ` Martin Storsjö
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e89d06c-847c-72f-28e-a956a45e44a5@martin.st \
--to=martin@martin.st \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git