moonchen opened a new pull request, #13318:
URL: https://github.com/apache/trafficserver/pull/13318

   Several error and early-return paths in the TLS server certificate loading 
and OCSP stapling code omit cleanup and leak native objects.  Most are gated on 
misconfiguration (bad or unreadable cert files) or allocation failure, so they 
accumulate slowly rather than on every handshake.
   
   1. setClientCertCACerts leaked the X509_STORE when X509_STORE_load_locations 
failed; the store is only adopted by SSL_set0_verify_cert_store on success. 
This fires per handshake on the sni.yaml verify_client path when the CA file or 
directory is bad.
   2. SSLNetVConnection::populate leaked the migrated SSL object when the base 
populate failed: the source VC has already relinquished ownership, so the SSL 
must be freed when this VC does not adopt it.
   3. load_certs leaked the leaf certificate on the mid-chain failure returns 
(bad intermediate chain, private key, or CA file).  The leaf is now held in a 
scoped_X509 so every path releases it.
   4. _prep_ssl_ctx and SSLCreateServerContext leaked already-parsed leaves 
when load_certs_and_cross_reference_names failed partway, because the X509_free 
drain was skipped on the early return.
   5. set_session_id_context leaked the client CA name stack on the digest 
error paths that run before ownership is handed to the SSL_CTX.
   6. ssl_callback_ocsp_stapling leaked the OCSP response buffer when 
SSL_set_tlsext_status_ocsp_resp failed; it only takes ownership of the buffer 
on success and the return value was ignored.
   7. stapling_refresh_response leaked the duplicated OCSP CERTID when 
TS_OCSP_request_add0_id failed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to