]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MEDIUM: mux-h1: make h1_shutw_conn() idempotent
authorWilly Tarreau <w@1wt.eu>
Fri, 26 Mar 2021 08:09:42 +0000 (09:09 +0100)
committerWilly Tarreau <w@1wt.eu>
Fri, 26 Mar 2021 08:29:38 +0000 (09:29 +0100)
In issue #1197, Stéphane Graber reported a rare case of crash that
results from an attempt to close an already closed H1 connection. It
indeed looks like under some circumstances it should be possible to
call the h1_shutw_conn() function more than once, though these
conditions are not very clear.

Without going through a deep analysis of all possibilities, one
potential case seems to be a detach() called with pending output data,
causing H1C_F_ST_SHUTDOWN to be set on the connection, then h1_process()
being immediately called on I/O, causing h1_send() to flush these data
and call h1_shutw_conn(), and finally the upper stream calling cs_shutw()
hence h1_shutw(), which itself will call h1_shutw_conn() again while the
transport and control layers have already been released. But the whole
sequence is not certain as it's not very clear in which case it's
possible to leave h1_send() without the connection anymore (at least
the obuf is empty).

However what is certain is that a shutdown function must be idempotent,
so let's fix h1_shutw_conn() regarding this point. Stéphane reported the
issue as far back as 2.0, so this patch should be backported this far.

src/mux_h1.c

index ca2e8a85375b3c98ea623e85f3c85e7e723dbe02..656c0a1bce2f97527033a25eff733f42fffe943a 100644 (file)
@@ -3238,6 +3238,9 @@ static void h1_shutw_conn(struct connection *conn, enum cs_shw_mode mode)
 {
        struct h1c *h1c = conn->ctx;
 
+       if (conn->flags & CO_FL_SOCK_WR_SH)
+               return;
+
        TRACE_ENTER(H1_EV_STRM_SHUT, conn, h1c->h1s);
        conn_xprt_shutw(conn);
        conn_sock_shutw(conn, (mode == CS_SHW_NORMAL));