Potential memory leak of TlsContext in WriteCryptoFrame in recvfuzz

[t-minzheng]

Description

The WriteCryptoFrame function performs a heap allocation of TlsContext using new (line 533), but:

• The ClientContext parameter is passed by value, so any assignment to it inside the function does not propagate back to the caller, so cannot be deleted in the caller.

• The newly allocated TlsContext is never deleted, resulting in a memory leak.

msquic/src/tools/recvfuzz/recvfuzz.cpp

Lines 522 to 562 in 6f5b5a1

	void WriteCryptoFrame(
	_Inout_ uint16_t* Offset,
	_In_ uint16_t BufferLength,
	_Out_writes_to_(BufferLength, *Offset)
	uint8_t* Buffer,
	_In_ TlsContext* ClientContext,
	_In_ PacketParams* PacketParams
	)
	{
	if (PacketParams->Mode == 0) {
	if (ClientContext == nullptr) {
	ClientContext = new TlsContext();
	ClientContext->CreateContext(PacketParams->SourceCid);
	auto Result = ClientContext->ProcessData();
	CXPLAT_FRE_ASSERT(Result & CXPLAT_TLS_RESULT_DATA);
	}
	}
	QUIC_CRYPTO_EX Frame = {
	0, ClientContext->State.BufferLength, ClientContext->State.Buffer
	};
	//
	// TODO: The code in the recvfuzzer assumes that all data produced in
	// a single pass through CxPlatTlsProcessData will fit in a udp datagram
	// which is not the case with openssl when ML-KEM keyshares are offered.
	// We should update this code to allow for the splitting of CRYPTO frames
	// in the same way the core datapath does. Until then, we disable ML-KEM
	// for the fuzzer only (see corresponding TODO in tls_openssl.c
	//
	CXPLAT_FRE_ASSERT(
	QuicCryptoFrameEncode(
	&Frame,
	Offset,
	BufferLength,
	Buffer));
	}
	//
	// Build up the packet header and payload.
	//

Impact

• The leakage happens on every call that provides a null TLS context as argument and PacketParams->Mode == 0