[asan] Detect dereferencing zero-alloc as heap buffer overflow by thurstond · Pull Request #155943 · llvm/llvm-project

thurstond · 2025-08-28T23:14:14Z

When a zero-byte allocation is requested, ASan actually allocates 1-byte for compatibility. This change poisons that byte, to detect dereferences.

Also updates the test from #155933

When a zero-byte allocation is requested, ASan actually allocates 1-byte for compatibility. This change poisons that byte, to detect dereferences. Also updates the test from llvm#155933

llvmbot · 2025-08-28T23:14:50Z

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Thurston Dang (thurstond)

Changes

When a zero-byte allocation is requested, ASan actually allocates 1-byte for compatibility. This change poisons that byte, to detect dereferences.

Also updates the test from #155933

Full diff: https://github.com/llvm/llvm-project/pull/155943.diff

2 Files Affected:

(modified) compiler-rt/lib/asan/asan_allocator.cpp (+6)
(modified) compiler-rt/test/asan/TestCases/zero_alloc.cpp (-4)

diff --git a/compiler-rt/lib/asan/asan_allocator.cpp b/compiler-rt/lib/asan/asan_allocator.cpp
index 9ebe4d08ec8c1..752ba9ab32c71 100644
--- a/compiler-rt/lib/asan/asan_allocator.cpp
+++ b/compiler-rt/lib/asan/asan_allocator.cpp
@@ -547,6 +547,7 @@ struct Allocator {
         ComputeUserRequestedAlignmentLog(alignment);
     if (alignment < min_alignment)
       alignment = min_alignment;
+    bool upgraded_from_zero = false;
     if (size == 0) {
       // We'd be happy to avoid allocating memory for zero-size requests, but
       // some programs/tests depend on this behavior and assume that malloc
@@ -555,6 +556,7 @@ struct Allocator {
       // consecutive "new" calls must be different even if the allocated size
       // is zero.
       size = 1;
+      upgraded_from_zero = true;
     }
     CHECK(IsPowerOfTwo(alignment));
     uptr rz_log = ComputeRZLog(size);
@@ -637,6 +639,10 @@ struct Allocator {
       *shadow = fl.poison_partial ? (size & (ASAN_SHADOW_GRANULARITY - 1)) : 0;
     }
 
+    if (upgraded_from_zero)
+      PoisonShadow(user_beg, ASAN_SHADOW_GRANULARITY,
+                   kAsanHeapLeftRedzoneMagic);
+
     AsanStats &thread_stats = GetCurrentThreadStats();
     thread_stats.mallocs++;
     thread_stats.malloced += size;
diff --git a/compiler-rt/test/asan/TestCases/zero_alloc.cpp b/compiler-rt/test/asan/TestCases/zero_alloc.cpp
index d25164a1e2eb9..e843a5a41f429 100644
--- a/compiler-rt/test/asan/TestCases/zero_alloc.cpp
+++ b/compiler-rt/test/asan/TestCases/zero_alloc.cpp
@@ -1,9 +1,5 @@
 // RUN: %clang_asan -Wno-alloc-size -fsanitize-recover=address %s -o %t && %env_asan_opts=halt_on_error=0 %run %t 2>&1 | FileCheck %s
 
-// ASan doesn't catch this because internally it translates 0-byte allocations
-// into 1-byte
-// XFAIL: *
-
 #include <malloc.h>
 #include <stdio.h>

ASan now detects dereferences of zero-sized allocations (llvm#155943). This appears to have detected a bug in CrossOverTest.cpp, which this patch fixes. Buildbot: https://lab.llvm.org/buildbot/#/builders/4/builds/8732 7: ==949882==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf169cfbe0010 at pc 0xb5f45efc6d1c bp 0xffffd933e460 sp 0xffffd933e458 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 8: READ of size 1 at 0xf169cfbe0010 thread T0 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 9: #0 0xb5f45efc6d18 in LLVMFuzzerTestOneInput /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/test/fuzzer/CrossOverTest.cpp:48:7 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:20'1 ? possible intended match 10: #1 0xb5f45eec7288 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 11: llvm#2 0xb5f45eec85d4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:812:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12: llvm#3 0xb5f45eec8c60 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:872:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13: llvm#4 0xb5f45eeb5c64 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:923:6 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14: llvm#5 0xb5f45eee09d0 in main /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

…build breakage from #155943) (#156103) ASan now detects dereferences of zero-sized allocations (#155943; the corresponding MSan change is #155944). This appears to have detected a bug in CrossOverTest.cpp, causing a buildbot breakage. This patch fixes the test. Buildbot report: https://lab.llvm.org/buildbot/#/builders/4/builds/8732 ``` 7: ==949882==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf169cfbe0010 at pc 0xb5f45efc6d1c bp 0xffffd933e460 sp 0xffffd933e458 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 8: READ of size 1 at 0xf169cfbe0010 thread T0 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 9: #0 0xb5f45efc6d18 in LLVMFuzzerTestOneInput /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/test/fuzzer/CrossOverTest.cpp:48:7 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:20'1 ? possible intended match 10: #1 0xb5f45eec7288 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 11: #2 0xb5f45eec85d4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:812:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12: #3 0xb5f45eec8c60 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:872:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13: #4 0xb5f45eeb5c64 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:923:6 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14: #5 0xb5f45eee09d0 in main /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` For context, FuzzerLoop.cpp:812 tries empty input: ``` 810 // Test the callback with empty input and never try it again. 811 uint8_t dummy = 0; 812 ExecuteCallback(&dummy, 0); ```

…ix-forward build breakage from #155943) (#156103) ASan now detects dereferences of zero-sized allocations (llvm/llvm-project#155943; the corresponding MSan change is llvm/llvm-project#155944). This appears to have detected a bug in CrossOverTest.cpp, causing a buildbot breakage. This patch fixes the test. Buildbot report: https://lab.llvm.org/buildbot/#/builders/4/builds/8732 ``` 7: ==949882==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf169cfbe0010 at pc 0xb5f45efc6d1c bp 0xffffd933e460 sp 0xffffd933e458 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 8: READ of size 1 at 0xf169cfbe0010 thread T0 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 9: #0 0xb5f45efc6d18 in LLVMFuzzerTestOneInput /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/test/fuzzer/CrossOverTest.cpp:48:7 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:20'1 ? possible intended match 10: #1 0xb5f45eec7288 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 11: #2 0xb5f45eec85d4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:812:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12: #3 0xb5f45eec8c60 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:872:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13: #4 0xb5f45eeb5c64 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:923:6 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14: #5 0xb5f45eee09d0 in main /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` For context, FuzzerLoop.cpp:812 tries empty input: ``` 810 // Test the callback with empty input and never try it again. 811 uint8_t dummy = 0; 812 ExecuteCallback(&dummy, 0); ```

vitalybuka · 2025-08-30T01:58:43Z

Windows is broken https://lab.llvm.org/staging/#/builders/37

thurstond · 2025-08-30T02:19:04Z

Windows is broken https://lab.llvm.org/staging/#/builders/37

Same issue that has already been fixed; fix hasn't landed on the Windows bot. Windows bots are surprisingly slow.
e.g., the most recently finished bot run (https://lab.llvm.org/staging/#/builders/37/builds/713) is building off:

Date	August 29, 2025 11:24 AM (8 hours ago)
Revision	0499eb83fa92001d7f72623e2954bf2c340e0f79

thurstond · 2025-08-30T03:18:20Z

Windows is broken https://lab.llvm.org/staging/#/builders/37

Same issue that has already been fixed; fix hasn't landed on the Windows bot. Windows bots are surprisingly slow. e.g., the most recently finished bot run (https://lab.llvm.org/staging/#/builders/37/builds/713) is building off:
Date	August 29, 2025 11:24 AM (8 hours ago)
Revision	0499eb83fa92001d7f72623e2954bf2c340e0f79

Windows bot is green now: https://lab.llvm.org/staging/#/builders/37/builds/714

mstorsjo · 2025-08-30T21:12:01Z

This change broke test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp on 32 bit Windows - see https://github.com/mstorsjo/llvm-mingw/actions/runs/17337326265/job/49243607453:

# error: command failed with exit status: 1
# executed command: FileCheck 'D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp'
# .---command stderr------------
# | D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp:56:15: error: CHECK-NOT: excluded string found in input
# | // CHECK-NOT: heap-buffer-overflow
# |               ^
# | <stdin>:3:34: note: found here
# | ==7036==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x01d00770 at pc 0x005e140f bp 0x00cffc94 sp 0x00cffc90
# |                                  ^~~~~~~~~~~~~~~~~~~~
# | D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp:57:15: error: CHECK-NOT: excluded string found in input
# | // CHECK-NOT: AddressSanitizer
# |               ^
# | <stdin>:3:16: note: found here
# | ==7036==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x01d00770 at pc 0x005e140f bp 0x00cffc94 sp 0x00cffc90
# |                ^~~~~~~~~~~~~~~~
# | 
# | Input file: <stdin>
# | Check file: D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp
# | 
# | -dump-input=help explains the following input dump.
# | 
# | Input was:
# | <<<<<<
# |         1: allocated! 
# |         2: ================================================================= 
# |         3: ==7036==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x01d00770 at pc 0x005e140f bp 0x00cffc94 sp 0x00cffc90 
# | not:56                                      !~~~~~~~~~~~~~~~~~~~                                                                     error: no match expected
# | not:57                    !~~~~~~~~~~~~~~~                                                                                           error: no match expected
# |         4: WRITE of size 1 at 0x01d00770 thread T0 
# |         5:  #0 0x005e140e in main D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows/heaprealloc_alloc_zero.cpp:12:20 
# |         6:  #1 0x005e10d3 in __tmainCRTStartup /home/runner/work/llvm-mingw/llvm-mingw/mingw-w64/mingw-w64-crt/build-i686/../crt/crtexe.c:236:11 
# |         7:  #2 0x772067f8 (C:\Windows\System32\KERNEL32.DLL+0x6b8167f8) 
# |         8:  #3 0x77df7f4c (C:\Windows\SYSTEM32\ntdll.dll+0x4b2e7f4c) 
# |         .
# |         .
# |         .
# | >>>>>>
# `-----------------------------
# error: command failed with exit status: 1

This test has // UNSUPPORTED: asan-64-bits at https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/asan/TestCases/Windows/heaprealloc_alloc_zero.cpp#L3, so this test case isn't executed in most common 64 bit environments.

The test checks that 1-byte is allocated when malloc(0) is called, by dereferencing the pointer. llvm#155943 changed ASan to consider the dereference to be a heap buffer overflow. This patch changes the test to check the allocated size is still 1-byte, but not dereference the pointer. This aims to fix the breakage reported in llvm#155943 (comment)

thurstond · 2025-08-30T21:54:37Z

This change broke test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp on 32 bit Windows - see https://github.com/mstorsjo/llvm-mingw/actions/runs/17337326265/job/49243607453:

# error: command failed with exit status: 1
# executed command: FileCheck 'D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp'
# .---command stderr------------
# | D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp:56:15: error: CHECK-NOT: excluded string found in input
# | // CHECK-NOT: heap-buffer-overflow
# |               ^
# | <stdin>:3:34: note: found here
# | ==7036==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x01d00770 at pc 0x005e140f bp 0x00cffc94 sp 0x00cffc90
# |                                  ^~~~~~~~~~~~~~~~~~~~
# | D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp:57:15: error: CHECK-NOT: excluded string found in input
# | // CHECK-NOT: AddressSanitizer
# |               ^
# | <stdin>:3:16: note: found here
# | ==7036==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x01d00770 at pc 0x005e140f bp 0x00cffc94 sp 0x00cffc90
# |                ^~~~~~~~~~~~~~~~
# | 
# | Input file: <stdin>
# | Check file: D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows\heaprealloc_alloc_zero.cpp
# | 
# | -dump-input=help explains the following input dump.
# | 
# | Input was:
# | <<<<<<
# |         1: allocated! 
# |         2: ================================================================= 
# |         3: ==7036==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x01d00770 at pc 0x005e140f bp 0x00cffc94 sp 0x00cffc90 
# | not:56                                      !~~~~~~~~~~~~~~~~~~~                                                                     error: no match expected
# | not:57                    !~~~~~~~~~~~~~~~                                                                                           error: no match expected
# |         4: WRITE of size 1 at 0x01d00770 thread T0 
# |         5:  #0 0x005e140e in main D:\a\llvm-mingw\llvm-mingw\llvm-project\compiler-rt\test\asan\TestCases\Windows/heaprealloc_alloc_zero.cpp:12:20 
# |         6:  #1 0x005e10d3 in __tmainCRTStartup /home/runner/work/llvm-mingw/llvm-mingw/mingw-w64/mingw-w64-crt/build-i686/../crt/crtexe.c:236:11 
# |         7:  #2 0x772067f8 (C:\Windows\System32\KERNEL32.DLL+0x6b8167f8) 
# |         8:  #3 0x77df7f4c (C:\Windows\SYSTEM32\ntdll.dll+0x4b2e7f4c) 
# |         .
# |         .
# |         .
# | >>>>>>
# `-----------------------------
# error: command failed with exit status: 1

This test has // UNSUPPORTED: asan-64-bits at https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/asan/TestCases/Windows/heaprealloc_alloc_zero.cpp#L3, so this test case isn't executed in most common 64 bit environments.

Sorry for the breakage. I've drafted #156211 which I think will fix it.

…nce (#156211) The test currently checks that 1-byte is allocated when malloc(0) is called, by dereferencing the pointer. #155943 changed ASan to consider the dereference to be a heap buffer overflow. This patch changes the test to check the allocated size is still 1-byte, but not dereference the pointer. This aims to fix the breakage reported in #155943 (comment) It also enables the test for 64-bit Windows.

…id dereference (#156211) The test currently checks that 1-byte is allocated when malloc(0) is called, by dereferencing the pointer. llvm/llvm-project#155943 changed ASan to consider the dereference to be a heap buffer overflow. This patch changes the test to check the allocated size is still 1-byte, but not dereference the pointer. This aims to fix the breakage reported in llvm/llvm-project#155943 (comment) It also enables the test for 64-bit Windows.

zmodem · 2025-09-02T09:45:53Z

It broke Mac too: https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/5301/testReport/junit/AddressSanitizer-x86_64-darwin/TestCases/zero_alloc_cpp/

Could it just include <stdlib.h> instead of <malloc.h>?

I'll mark it unsupported on mac for now.

It's failing due to the malloc.h include, see comment on #155943

It's failing due to the malloc.h include, see comment on llvm/llvm-project#155943

thurstond · 2025-09-02T16:47:15Z

It broke Mac too: https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/5301/testReport/junit/AddressSanitizer-x86_64-darwin/TestCases/zero_alloc_cpp/

Could it just include <stdlib.h> instead of <malloc.h>?

I'll mark it unsupported on mac for now.

Sorry for the breakage, and thanks for marking it unsupported for now.

I'll update it to use <stdlib.h>.

Avoid build breakage on Mac (reported at llvm#155943 (comment))

…ac (#156490) Avoid build breakage on Mac (reported at #155943 (comment))

…enable on Mac (#156490) Avoid build breakage on Mac (reported at llvm/llvm-project#155943 (comment))

…81015) This is a follow up to #155943 On Windows, ASan's allocator internally upgrades zero-size allocation requests to size 1 (since malloc(0) must return a unique non-NULL pointer). However, when the user queries the allocation size through Windows heap APIs (RtlSizeHeap, HeapSize, \_msize, GlobalSize, LocalSize), ASan reports the internal size (1) instead of the originally requested size (0). This causes false positive heap-buffer-overflow errors in a common pattern: ```c++ void *buf = HeapAlloc(GetProcessHeap(), 0, 0); SIZE_T size = HeapSize(GetProcessHeap(), 0, buf); // Returns 1, should be 0 if(size > 0) // could remove this and still be correct memset(buf, 0, size); // ASan reports heap-buffer-overflow ``` The change adds a `from_zero_alloc` bit to `ChunkHeader` that tracks whether an allocation was originally zero-size. This bit fits in the existing spare capacity of the header's bitfield byte, so the 16-byte ChunkHeader size is unchanged, but it also isn't the most elegant. The 1-byte user region of a zero-size allocation is still poisoned, so any actual access to it is correctly reported as an overflow.

…vm#181015) This is a follow up to llvm#155943 On Windows, ASan's allocator internally upgrades zero-size allocation requests to size 1 (since malloc(0) must return a unique non-NULL pointer). However, when the user queries the allocation size through Windows heap APIs (RtlSizeHeap, HeapSize, \_msize, GlobalSize, LocalSize), ASan reports the internal size (1) instead of the originally requested size (0). This causes false positive heap-buffer-overflow errors in a common pattern: ```c++ void *buf = HeapAlloc(GetProcessHeap(), 0, 0); SIZE_T size = HeapSize(GetProcessHeap(), 0, buf); // Returns 1, should be 0 if(size > 0) // could remove this and still be correct memset(buf, 0, size); // ASan reports heap-buffer-overflow ``` The change adds a `from_zero_alloc` bit to `ChunkHeader` that tracks whether an allocation was originally zero-size. This bit fits in the existing spare capacity of the header's bitfield byte, so the 16-byte ChunkHeader size is unchanged, but it also isn't the most elegant. The 1-byte user region of a zero-size allocation is still poisoned, so any actual access to it is correctly reported as an overflow.

[asan] Detect dereferencing zero-alloc as heap buffer overflow

4b20248

When a zero-byte allocation is requested, ASan actually allocates 1-byte for compatibility. This change poisons that byte, to detect dereferences. Also updates the test from llvm#155933

thurstond requested review from dvyukov and fmayer August 28, 2025 23:14

llvmbot added compiler-rt compiler-rt:asan Address sanitizer compiler-rt:sanitizer labels Aug 28, 2025

fmayer approved these changes Aug 28, 2025

View reviewed changes

thurstond merged commit b3452d9 into llvm:main Aug 29, 2025
13 checks passed

thurstond mentioned this pull request Aug 29, 2025

[fuzzer] Avoid buffer overflow in CrossOverTest.cpp (and fix-forward build breakage from #155943) #156103

Merged

thurstond mentioned this pull request Aug 30, 2025

Revert "[msan] Detect dereferencing zero-alloc as use-of-uninitialized-value" #156148

Closed

thurstond mentioned this pull request Aug 30, 2025

[asan] Rewrite Windows/heaprealloc_alloc_zero check to avoid dereference #156211

Merged

zmodem added a commit that referenced this pull request Sep 2, 2025

Mark asan/TestCases/zero_alloc.cpp unsupported on Mac for now

a6bd36e

It's failing due to the malloc.h include, see comment on #155943

llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request Sep 2, 2025

Automerge: Mark asan/TestCases/zero_alloc.cpp unsupported on Mac for now

67f6fb2

It's failing due to the malloc.h include, see comment on llvm/llvm-project#155943

thurstond added a commit to thurstond/llvm-project that referenced this pull request Sep 2, 2025

[asan] Change zero_alloc.cpp testcase to use stdlib.h, re-enable on Mac

3d7e37f

Avoid build breakage on Mac (reported at llvm#155943 (comment))

thurstond mentioned this pull request Sep 2, 2025

[asan] Change zero_alloc.cpp testcase to use stdlib.h, re-enable on Mac #156490

Merged

thurstond added a commit that referenced this pull request Sep 2, 2025

[asan] Change zero_alloc.cpp testcase to use stdlib.h, re-enable on M…

e2a8b98

…ac (#156490) Avoid build breakage on Mac (reported at #155943 (comment))

llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request Sep 2, 2025

Automerge: [asan] Change zero_alloc.cpp testcase to use stdlib.h, re-…

a8506b0

…enable on Mac (#156490) Avoid build breakage on Mac (reported at llvm/llvm-project#155943 (comment))

zacklj89 mentioned this pull request Feb 11, 2026

[ASan][Windows] Fix false positive for zero sized rtl allocations #181015

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[asan] Detect dereferencing zero-alloc as heap buffer overflow#155943

[asan] Detect dereferencing zero-alloc as heap buffer overflow#155943
thurstond merged 1 commit intollvm:mainfrom
thurstond:asan_zero_alloc

thurstond commented Aug 28, 2025

Uh oh!

llvmbot commented Aug 28, 2025

Uh oh!

Uh oh!

vitalybuka commented Aug 30, 2025

Uh oh!

thurstond commented Aug 30, 2025 •

edited

Loading

Uh oh!

thurstond commented Aug 30, 2025

Uh oh!

mstorsjo commented Aug 30, 2025

Uh oh!

thurstond commented Aug 30, 2025

Uh oh!

zmodem commented Sep 2, 2025

Uh oh!

thurstond commented Sep 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

thurstond commented Aug 28, 2025

Uh oh!

llvmbot commented Aug 28, 2025

Uh oh!

Uh oh!

vitalybuka commented Aug 30, 2025

Uh oh!

thurstond commented Aug 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thurstond commented Aug 30, 2025

Uh oh!

mstorsjo commented Aug 30, 2025

Uh oh!

thurstond commented Aug 30, 2025

Uh oh!

zmodem commented Sep 2, 2025

Uh oh!

thurstond commented Sep 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

thurstond commented Aug 30, 2025 •

edited

Loading