net9 regression: Assembly.GetCallingAssembly() together with stackalloc of 1024 bytes results in Exception code: 0xc0000409

[Donis-]

Description

We started getting 0xc0000409 STATUS_STACK_BUFFER_OVERRUN exceptions after switching to .net9
Example from eventviewer:

Faulting application name: ConsoleApp2.exe, version: 1.0.0.0, time stamp: 0x67200000
Faulting module name: coreclr.dll, version: 9.0.24.52809, time stamp: 0x672049fc
Exception code: 0xc0000409
Fault offset: 0x000000000015864d
Faulting process id: 0x14548
Faulting application start time: 0x1DB65C13A806A12
Faulting application path: C:\Users\don\source\repos\ConsoleApp2\ConsoleApp2\bin\Debug\net9.0\ConsoleApp2.exe
Faulting module path: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\9.0.0\coreclr.dll
Report Id: a90a803c-06e1-4505-a11e-7b89154a9457
Faulting package full name: 
Faulting package-relative application ID: 

Reproduction Steps

Minimal reproducible example Program.cs in a .net9 console project :

using System.Reflection;
Span<byte> err = stackalloc byte[1024];
Assembly.GetCallingAssembly();

ConsoleApp2.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

This results in the attached coredump ConsoleApp2.exe.83272
ConsoleApp2.exe.83272.zip

Native call stack:

>	coreclr.dll!__report_gsfailure(unsigned __int64 stack_cookie) Line 220	C
 	[Inline Frame] coreclr.dll!DoJITFailFast() Line 3298	C++
 	coreclr.dll!CrawlFrame::CheckGSCookies() Line 363	C++
 	[Inline Frame] coreclr.dll!StackFrameIterator::PreProcessingForManagedFrames() Line 3193	C++
 	[Inline Frame] coreclr.dll!StackFrameIterator::ProcessCurrentFrame() Line 3029	C++
 	coreclr.dll!StackFrameIterator::NextRaw() Line 2812	C++
 	[Inline Frame] coreclr.dll!StackFrameIterator::Next() Line 1623	C++
 	coreclr.dll!Thread::StackWalkFramesEx(REGDISPLAY * pRD, StackWalkAction(*)(CrawlFrame *, void *) pCallback, void * pData, unsigned int flags, Frame * pStartFrame) Line 917	C++
 	coreclr.dll!Thread::StackWalkFrames(StackWalkAction(*)(CrawlFrame *, void *) pCallback, void * pData, unsigned int flags, Frame * pStartFrame) Line 992	C++
 	coreclr.dll!SystemDomain::GetCallersModule(StackCrawlMark * stackMark) Line 1495	C++
 	[Inline Frame] coreclr.dll!SystemDomain::GetCallersAssembly(StackCrawlMark *) Line 1511	C++
 	coreclr.dll!AssemblyNative_GetExecutingAssembly(QCall::StackCrawlMarkHandle stackMark, QCall::ObjectHandleOnStack retAssembly) Line 1139	C++
 	System.Private.CoreLib.dll!00007ffe98386db7()	Unknown

    m_pCachedGSCookie = (GSCookie*)m_crawl.GetCodeManager()->GetGSCookieAddr(
                                                        m_crawl.pRD,
                                                        &m_crawl.codeInfo,
                                                        &m_crawl.codeManState);

Value of *m_pCachedGSCookie is actually 0, but it's compared against 0x0000f0153d9f2e0a ?

We tried analyzing the issue in a different, our production application coredump, and it seemed the cookie address m_pCachedGSCookie retrieved during stack walking was off by the size of of the stackalloc, in our case it was off by 1024 bytes.

Expected behavior

No crash

Actual behavior

Crash with 0xc0000409 STATUS_STACK_BUFFER_OVERRUN

Regression?

Yes, no issue in .net8

Known Workarounds

Not known at the time.

Configuration

.net9
windows 11
x64

Other information

No response

[Donis-]

Tried to disable CET support as other .net9 0xc0000409 issues were related to it:
https://learn.microsoft.com/en-us/dotnet/core/compatibility/interop/9.0/cet-support

Via:

    <CETCompat>false</CETCompat>

Same problem

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[EgorBo]

Doesn't repro on .net 10, perhaps, is fixed by some of the @AaronRobinsonMSFT PR?
Reproduces on net 9.

[EgorBo]

Ah, it's #109242, the fix is backported to .net 9 and should be available soon

[Donis-]

Thank you @EgorBo
Do you know or can help find out when is it likely that 9.0.1 will be released?

[martincostello]

Update Tuesday for January is tomorrow, so I would have thought 9.0.1 will land then, but the fix was only merged 4 days ago so I would have thought that's slipped to 9.0.2 and would be in February.