CVE-2021-22901: TLS session caching disaster

## Summary: lib/vtls/openssl.c `ossl_connect_step1` sets up the `ossl_new_session_cb` sessionid callback with `SSL_CTX_sess_set_new_cb`, and adds association from `data_idx` and `connectdata_idx` to current `conn` and `data` respectively: ``` SSL_CTX_set_session_cache_mode(backend->ctx, SSL_SESS_CACHE_CLIENT | SSL_SESS_CACHE_NO_INTERNAL); SSL_CTX_sess_set_new_cb(backend->ctx, ossl_new_session_cb); ``` ... ``` SSL_set_ex_data(backend->handle, data_idx, data); SSL_set_ex_data(backend->handle, connectdata_idx, conn); ``` Whenever the `ossl_new_session_cb` callback is called the code fetches the `conn` and `data` associated via: ``` conn = (struct connectdata*) SSL_get_ex_data(ssl, connectdata_idx); if(!conn) return 0; data = (struct Curl_easy *) SSL_get_ex_data(ssl, data_idx); ``` However, it is possible that the connection is disassociated from these pointers via `Curl_detach_connnection`, and reassociated to a different connection via `Curl_attach_connnection`. Yet, `Curl_detach_connnection` doesn't `SSL_set_ex_data` the `data_idx` / `connectdata_idx`/ to NULL, nor does `Curl_attach_connnection` update the pointers with new ones. I am not absolutely certain but this appears to lead to a situation where a stale pointer(s) can exists when the session callback is called. ## Steps To Reproduce: Unfortunately I currently have no easy to way reproduce this issue. I might attempt to do this later. ## Notes This issue is currently lacking information but includes what I believe is the potential root cause of the issue. This information might be wrong or lacking necessary details to make full determination of the validity of this issue at this time. This issue seems to be occurring somewhat periodically when webkit browser is built with the libcurl backend. Typically this is a rare use case, I know of only Sony Playstation devices that use in larger scale. ## Impact Use after free, with potential for (remote(*)) code execution as `ossl_new_session_cb` calls `Curl_ssl_sessionid_lock(data);` with potentially repurposed memory. Attacker would need to control `data->share` pointer to attacker controller memory. This fake `struct Curl_share` would need to be crafted in a way that `if(share->specifier & (1<<type))` is taken. `share->lockfunc` would then get called by the function, resulting in code execution. *) caveat here, as it is unknown if external attacker can trigger this situation. It would be difficult, but cannot be completely ruled out.