Update Crt helpers for Windows x64 to handle allocating outgoing args…

… space for the callee when ASAN is enabled to ensure we have the correct space allocated and don't crash when MSVC generates code for memset that uses that space.

src/coreclr/vm/amd64/CrtHelpers.asm

@@ -36,7 +36,24 @@ LEAF_ENTRY JIT_MemSet, _TEXT
 
         cmp     byte ptr [rcx], 0       ; check dest for null
 
+ifdef HAS_ASAN
+        ; For compatibility with ASAN, we need to assmume that the memset implementation will use
+        ; the register stack space to store its data (which it is allowed to do so according to the MSVC x64 ABI).
+        ; This should be handled in the JIT, but we don't want to add the additional cost of allocating this stack space
+        ; for every call to memset and due to when the JIT calculates the outgoing args space, this is very difficult to do in the JIT,
+        ; especially with trying to only do in scenarios where ASAN is enabled.
+        ; We don't need to do this in production scenarios as the CRT version is known to not do this.
+        ; Since we statically link the CRT, the memset version lives with CoreCLR and we don't need to worry about another ASAN-instrumented
+        ; binary interfering with it.
+
+        push    rbp
+        sub     rsp, 20h
+        call    memset
+        add     rsp, 20h
+        pop     rbp
+else
         jmp     memset                  ; forward to the CRT implementation
+endif
 
 Exit_MemSet:
         ret
@@ -70,7 +87,24 @@ LEAF_ENTRY JIT_MemCpy, _TEXT
         ; Use memmove to handle overlapping buffers for better
         ; compatibility with .NET Framework. Needing to handle
         ; overlapping buffers in cpblk is undefined by the spec.
+ifdef HAS_ASAN
+        ; For compatibility with ASAN, we need to assmume that the memmove implementation will use
+        ; the register stack space to store its data (which it is allowed to do so according to the MSVC x64 ABI).
+        ; This should be handled in the JIT, but we don't want to add the additional cost of allocating this stack space
+        ; for every call to memmove and due to when the JIT calculates the outgoing args space, this is very difficult to do in the JIT,
+        ; especially with trying to only do in scenarios where ASAN is enabled.
+        ; We don't need to do this in production scenarios as the CRT version is known to not do this.
+        ; Since we statically link the CRT, the memset version lives with CoreCLR and we don't need to worry about another ASAN-instrumented
+        ; binary interfering with it.
+
+        push    rbp
+        sub     rsp, 20h
+        call    memmove
+        add     rsp, 20h
+        pop     rbp
+else
         jmp     memmove                 ; forward to the CRT implementation
+endif
 
 Exit_MemCpy:
         ret