Could you please elaborate more on how exactly to reproduce this issue? From the branch name it follows that the primary way to do it is by using the ssi module. Just triggering the error in the code and running ssi.t is not enough though. There should be a setting where the malformed subrequest is taken from c->data and processed. After finalizing the subrequest, the counter is decremented and the main request is processed. Finalizing the main request will trigger the error.

Normally, a subrequest error finalizes the entire main request (see addition for example). In this case c->data is usually not accessed, unless mr->blocked is set (see ngx_http_terminate_request) but that's a rare case. Changing the counter behavior would damage this case since the subrequest is not registered anywhere but in c->data. SSI module however is an exception where a failed subrequest is ignored and may remain active and potentially lead to the consequences described.

Looks like a simple way to access a request from c->data is limit_rate. Adding a simple limit_rate to the test did not trigger the issue though, probably more finetuning is needed.

Indeed, both cases are explained by proxied subrequests initiated by SSI "virtual" command,
with the below sample config, where ssi.html contains included (sub)request(s) matched by "location /proxy-":

        location /ssi.html {
            ssi on;
        }

        location /proxy- {
            proxy_pass http://u/;
        }

In the basic scenario, with a single failing subrequest, request count zero alerts are papered over by r->count reset to 1 in ngx_http_terminate_handler().
Here, after ngx_http_subrequest() error, the processing will end up in send timeout that will kick in ngx_http_request_handler() for the given active subrequest, where it will initiate request proxying. After its normal processing and finalization, a parent request will be awaken and, due to send timeout, it will get into ngx_http_terminate_request() with request count zero. Here it is posted with ngx_http_terminate_handler() that resets r->count to 1. No socket leaks, no alerts.

With two included requests in ssi.html the behaviour is different, such as in:

<!--#include virtual="/proxy-index.html?1" -->
<!--#include virtual="/proxy-index.html?2" -->

Here, after failing 1st subrequest, the 2nd is run posted. Then the 1st (active) subrequest will be normally run on upstream write event. Eventually, after normal processing and finalizing both subrequests, r->count is zero.

In addition to the above, consider the 1st failing subrequest finished its processing first (or it served static content), and a parent request was awaken, where it then posts 2nd subrequest from the postpone filter. Here, ngx_http_post_request() additional error results in main request termination with terminate request count:1. This calls in turn all cleanup handlers including registered from subrequests. Such one is ngx_http_upstream_cleanup() for the 2nd subrequest, which may end up in ngx_http_finalize_request(NGX_DONE), and due to the wrong request count, in ngx_http_close_request() for the main request, which ultimately will destroy request pool. Sanitizer catches this U-A-F on the next cln->next, otherwise it may or may not segfault depending on how far the freed request was damaged.

SSI module however is an exception where a failed subrequest is ignored and may remain active and potentially lead to the consequences described.

Changing SSI module behaviour to return NGX_ERROR looks like a separate change, which might have pitfails.
For now, I suggest to fix ngx_http_subrequest() initialization order to eliminate inconsistency (see updated patch).

The patch looks ok, as discussed before. However, I think the commit log needs a clarification about the fact that the issue only manifests itself with the ssi module, which ignores ngx_http_subrequest() errors.

As mentioned above, fixing the ssi module to treat such errors as fatal could be an alternative solution. However, ngx_http_subrequest() leaving the requst in an inconsistent state is a problem as well.

The patch looks ok, as discussed before. However, I think the commit log needs a clarification ...

Agree, I don't like commit log either.
Please see updated.