mbedtls: client: fix ALPN stack-use-after-scope

[saghul]

In lws_ssl_client_bio_create() (mbedtls backend), the final else branch copies the ALPN from the ah into a temp_alpn[128] buffer scoped to that block and points alpn_comma at it:

} else {
    char temp_alpn[128];
    if (lws_hdr_copy(wsi, temp_alpn, sizeof(temp_alpn),
            _WSI_TOKEN_CLIENT_ALPN) > 0)
        alpn_comma = temp_alpn;
}   /* temp_alpn goes out of scope here */

if (alpn_comma) {
    ...
    lws_mbedtls_set_alpn(conn->ctx, alpn_comma);  /* reads out-of-scope stack */
}

lws_mbedtls_set_alpn() runs after the block closes and lws_strncpy()s alpn_comma into ctx->alpn_strings, so it reads out-of-scope stack.

This branch is taken for a client wsi that has no stash and carries its ALPN in the ah header — e.g. the QUIC→TCP fallback reset path (lws_client_h3_grace_cb → lws_client_reset), where an Alt-Svc-learned h3 origin whose QUIC path doesn't answer is retried over TCP. It happens to work in practice because the stack slot is usually not reused before the copy, but it is undefined behaviour.

ASAN reports it as stack-use-after-scope in lws_mbedtls_set_alpn (via lws_strncpy), reached from lws_ssl_client_bio_create.

Fix: hoist temp_alpn to function scope so it outlives the assignment. One-line move; no behaviour change on any path.

Verified downstream (txiki.js, mbedtls + native h3 Alt-Svc upgrade/fallback): the fallback test went from a reproducible stack-use-after-scope under ASAN to clean with this change.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud