Potential unbounded allocation in SizeOfField for ELEMENT_TYPE_ARRAY metadata signatures

[Babaijan]

Description

While reviewing ILDasm metadata processing code, I noticed a potential issue in SizeOfField when handling ELEMENT_TYPE_ARRAY signatures.

runtime/src/coreclr/ildasm/dasm_sz.cpp

Lines 182 to 188 in 98bfa17

	unsigned rank = CorSigUncompressData(*ppSig);
	if (rank == 0) ret = 0xFFFFFFFF;
	else
	{
	int* lowerBounds = new (nothrow) int[2*rank];
	int* sizes = &lowerBounds[rank];
	memset(lowerBounds, 0, sizeof(int)*2*rank);

new (nothrow) is implemented as follows and returns nullptr when memory is low.:

runtime/src/coreclr/nativeaot/Bootstrap/stdcppshim.cpp

Lines 13 to 16 in 98bfa17

	void* operator new(size_t n, const std::nothrow_t&) noexcept
	{
	return malloc(n);
	}

If new (nothrow) fails due to insufficient memory, lowerBounds becomes nullptr, the subsequent operations (&lowerBounds[rank] and memset) would dereference nullptr, causing a crash

Additional context

The .NET Runtime codebase typically includes null checks after new (nothrow) (e.g., ASSERTE_ALL_BUILDS(result != NULL) pattern). This appears to be an exception to that practice.

Question

Could you please take a look? Is this a genuine issue, or am I missing some context where allocation failure is handled differently here (e.g., rank is guaranteed to be small, or nothrow behavior is overridden)?

Thank you!

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @dotnet/jit-contrib
See info in area-owners.md if you want to be subscribed.