7817197780
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.
Compiler-RT ================================ This directory and its subdirectories contain source code for the compiler support routines. Compiler-RT is open source software. You may freely distribute it under the terms of the license agreement found in LICENSE.txt. ================================