[win/asan] Improve SharedReAlloc with HEAP_REALLOC_IN_PLACE_ONLY.

[bernhardu]

This patch allows reallocations in place if the size is below or equal to the initial allocated size.

Currently it prints only a "use-after-poison" message, not a proper "heap-buffer-overflow" with a hint to a reallocation.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[bernhardu]

Hello, I wonder if such a patch would be acceptable?

Also I am not sure which configurations this should be tested before final submission?
Currently I have only tested it with a maybe less used llvm-mingw configuration.

I found also most heap(re)alloc or rtlallocateheap tests contain an UNSUPPORTED: asan-64-bits or REQUIRES: asan-32-bits. Is there a reason known why these are currently not enabled for 64-bits?

[bernhardu]

Just corrected the clang-format.

Another point I forgot to mention, this currently creates an issue when running with ASAN_OPTIONS containing windows_hook_rtl_allocators=1", as it actually frees the memory which is attempted to be reallocated in place,
and shows a double-free when it gets regularly freed.

=================================================================
==mshtml_test.exe==1300==ERROR: AddressSanitizer: attempting double-free on 0x7f46b30bc800 in thread T-1:
    #0 0x6ffffe84b2e3 in RtlFreeHeap /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:431:3
    #1 0x6ffff3d7323f in FreeContextBuffer .../wine/dlls/secur32/secur32.c:651:5
    #2 0x6ffffe0aede4 in netcon_secure_connect_setup .../wine/dlls/wininet/netconnection.c:484:13
    #3 0x6ffffe0ae854 in NETCON_secure_connect .../wine/dlls/wininet/netconnection.c:612:11
    #4 0x6ffffe08141d in HTTP_HttpSendRequestW .../wine/dlls/wininet/http.c:5100:23
...

0x7f46b30bc800 is located 0 bytes inside of 65536-byte region [0x7f46b30bc800,0x7f46b30cc800)
freed by thread T0 here:
    #0 0x6ffffe84ada2 in __asan::SharedReAlloc(void* (*)(void*, unsigned long, void*, unsigned long long), unsigned long long (*)(void*, unsigned long, void*), int (*)(void*, unsigned long, void*), void* (*)(void*, unsigned long, unsigned long long), void*, unsigned long, void*, unsigned long long) /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:269:3
    #1 0x6ffffe84b174 in HeapReAlloc /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:381:10
    #2 0x6ffff3d6f0c3 in establish_context .../wine/dlls/secur32/schannel.c:979:13
    #3 0x6ffff3d6e400 in schan_InitializeSecurityContextW .../wine/dlls/secur32/schannel.c:1043:12
    #4 0x6ffff3d7a9f6 in InitializeSecurityContextW .../wine/dlls/secur32/wrapper.c:249:19
    #5 0x6ffffe0aecae in netcon_secure_connect_setup .../wine/dlls/wininet/netconnection.c:464:14
    #6 0x6ffffe0ae854 in NETCON_secure_connect .../wine/dlls/wininet/netconnection.c:612:11
    #7 0x6ffffe08141d in HTTP_HttpSendRequestW .../wine/dlls/wininet/http.c:5100:23
...

CC: @zmodem, @mstorsjo, what do you think?

[bernhardu]

To the question where this should be tested before submission, I wondered why the "Windows Premerge Check" did not run the tests. But then I found about .ci/compute-projects.sh function exclude-windows,
which contains compiler-rt) ;; # tests taking too long.

Is there any other way to submit a test to some buildbot or similar?

[mstorsjo]

To the question where this should be tested before submission, I wondered why the "Windows Premerge Check" did not run the tests. But then I found about .ci/compute-projects.sh function exclude-windows, which contains compiler-rt) ;; # tests taking too long.

Is there any other way to submit a test to some buildbot or similar?

I'm not aware of any such setup unfortunately...

But I use a custom github actions setup for test running various things on the public github actions runners - see mstorsjo@gha-mingw-compiler-rt. I pushed a combination of that with this test branch, which should produce results at https://github.com/mstorsjo/llvm-project/actions/runs/14078778580.

It should probably be possible to do a similar setup with clang-cl as well; it's mainly a question if it can be built with a recent enough separate build of clang (so one can build just compiler-rt), or if it requires a full build of clang+compiler-rt at the same time (which takes a fair bit of time on the github actions runners).

[bernhardu]

Thank you very much for the details and testing. Looks like the test succeeded here and here.
I will do some experiments.