]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MINOR: mux-fcgi: don't call fcgi_strm_destroy() on a NULL stream
authorOlivier Houchard <ohouchard@haproxy.com>
Thu, 6 Aug 2026 07:26:05 +0000 (09:26 +0200)
committerWilly Tarreau <w@1wt.eu>
Fri, 7 Aug 2026 08:29:19 +0000 (10:29 +0200)
fcgi_stconn_new() has three "goto out" taken before the stream is allocated
(streams limit reached, no stream left) or when the allocation failed, and
the out label unconditionally calls fcgi_strm_destroy(), which dereferences
<fstrm> right away. So a failure to allocate the stream or its tasklet
crashes instead of returning a clean error. The first two paths are
normally prevented by the reuse layer which checks avail_streams first.

Let's just skip the destruction when the stream is NULL.

This came with commit 070b91bc1 ("MEDIUM: conn-stream: Be prepared to fail
to attach a cs to a mux") in 2.6, which added this destroy call for the new
sc_attach_mux() failure path without protecting the pre-existing ones (the
other muxes did it right). It must be backported to all stable versions.

Reported-by: Claude (ANT-2026-VN29N97G)
src/mux_fcgi.c

index 6ec20dab13bed309886236ba9a7fe1b127a35729..16ccdfe428570d0e7a769398e727225feabd10f5 100644 (file)
@@ -1108,7 +1108,8 @@ static struct fcgi_strm *fcgi_stconn_new(struct fcgi_conn *fconn, struct stconn
 
   out:
        TRACE_DEVEL("leaving on error", FCGI_EV_FSTRM_NEW|FCGI_EV_FSTRM_END|FCGI_EV_FSTRM_ERR, fconn->conn);
-       fcgi_strm_destroy(fstrm);
+       if (fstrm)
+               fcgi_strm_destroy(fstrm);
        return NULL;
 }