Link peer's X509 stack handle to parent SSL safe handle

[rzikm]

Fixes#109689.

Fixes rare data race between handshake and SslStream.Dispose() where we would try to access already freed STACKOF(X509) and crash.

I also reviewed other interop usages to make sure there are no similar bugs lurking elsewhere on SslStream codebase.

Tested locally by inserting artificial delays at relevant places.

[Copilot]

PR Overview

This PR addresses a race condition during SSL/TLS handshakes by restructuring how the peer certificate chain is retrieved.

• Renames the original SslGetPeerCertChain method to a private implementation (SslGetPeerCertChain_private).
• Introduces a new public wrapper for SslGetPeerCertChain that uses SafeInteriorHandle.OpenInteriorHandle.

Reviewed Changes

File	Description
src/libraries/Common/src/Interop/Unix/System.Security.Cryptography.Native/Interop.Ssl.cs	Refactors peer certificate retrieval to link the parent SSL safe handle using a new wrapper method

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/libraries/Common/src/Interop/Unix/System.Security.Cryptography.Native/Interop.Ssl.cs:126

• [nitpick] Consider renaming 'SslGetPeerCertChain_private' to a more conventional name such as 'SslGetPeerCertChainCore' to clarify its role as the internal implementation detail.

internal static partial SafeSharedX509StackHandle SslGetPeerCertChain_private(SafeSslHandle ssl);

[wfurt]

LGTM.
Do we have confidence that we do not leak the handle anyhow?
And I'm wondering if we could add some test that would for example connect and dispose in loop. While not perfect and 100% reliable we would at least have some coverage for such scenarios e.g. disposing in middle of some operation.

[rzikm]

Do we have confidence that we do not leak the handle anyhow?

The usage in question puts the handle to a using block, the handle lives only while we get the entire cert chain from the SSL instance.

runtime/src/libraries/System.Net.Security/src/System/Net/CertificateValidationPal.Unix.cs

Lines 57 to 76 in 4a8a95f

	using(SafeSharedX509StackHandlechainStack=
	Interop.OpenSsl.GetPeerCertificateChain((SafeSslHandle)securityContext))
	{
	if(!chainStack.IsInvalid)
	{
	intcount=Interop.Crypto.GetX509StackFieldCount(chainStack);
	for(inti=0;i<count;i++)
	{
	IntPtrcertPtr=Interop.Crypto.GetX509StackField(chainStack,i);
	if(certPtr!=IntPtr.Zero)
	{
	// X509Certificate2(IntPtr) calls X509_dup, so the reference is appropriately tracked.
	X509Certificate2chainCert=newX509Certificate2(certPtr);
	chain.ChainPolicy.ExtraStore.Add(chainCert);
	}
	}
	}
	}

And I'm wondering if we could add some test that would for example connect and dispose in loop. While not perfect and 100% reliable we would at least have some coverage for such scenarios e.g. disposing in middle of some operation.

I will try and see how feasible it is.

[rzikm]

/ba-g Test failures are unrelated

[rzikm]

/backport to release/8.0-staging

[rzikm]

/backport to release/9.0-staging

[github-actions]

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/14891682108

[github-actions]

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/14891686789