AddressSanitizer __asan_cstring section and redzone padding behavior

Hi, I’m debugging an issue with AddressSanitizer (ASan) on macOS.

I’ve noticed that strings placed in the __asan_cstring section are aligned and padded with redzones. When I attempt to copy a contiguous block of memory (e.g., memcpy(buf, asan_cstring, 4096)), ASan throws an out-of-bounds access error.

On the other hand, strings in the __cstring section do not cause this problem, likely because they are laid out contiguously without redzone padding.

Could you clarify:

Are strings in __asan_cstring section aligned and padded individually with redzones?

Is this redzone inserted after each global string for alignment or instrumentation purposes?

Does this mean that bulk memory copies over this section (even if read-only) are inherently unsafe under ASan?

Is there a recommended way to safely iterate or copy memory from __asan_cstring without triggering ASan violations?

Any guidance on how redzones are managed in the __asan_cstring section would be very helpful.

Hi, it may be useful to provide some context as to why you are trying to bulk copy these strings, and how you are doing so. It is possible that what you are doing is unsafe, regardless of whether ASan is enabled or not. I'll try my best to answer your questions:

Are strings in __asan_cstring section aligned and padded individually with redzones?

These strings are treated as globals, and are padded with redzones.

Is this redzone inserted after each global string for alignment or instrumentation purposes?

The redzones are there to capture any out-of-bounds accesses; it is not valid to assume that reading past the end of a string will lead directly into the next string (or indeed that strings are laid out in any particular order).

Does this mean that bulk memory copies over this section (even if read-only) are inherently unsafe under ASan?

This means that bulk memory copies are inherently unsafe regardless of whether compiled with ASan.

Is there a recommended way to safely iterate or copy memory from __asan_cstring without triggering ASan violations?

You may be able to 'walk' through the section, avoiding any errors by using the __asan_address_is_poisoned function from the <sanitizers/asan_interface.h> header file to probe addresses before reading from them. That being said, you should only be doing this for educational or entertainment purposes; you are likely deeply into undefined behaviour territory here!

Note, I am assuming that you are reading this section by grabbing a pointer to a string that you know is in this section and making all accesses relative to this pointer. If you are using getsectiondata or similar to read the entire section then you can ignore my comments about undefined behaviour. If the 'walk' I describe above is not possible, then you can disable ASan global tracking when compiling with clang using the flags -mllvm -asan-globals=0; but be aware that this affects all globals, not just strings.

AddressSanitizer __asan_cstring section and redzone padding behavior
 
 
Q