[asan] Fix unknown-crash reported for multi-byte errors

[wxwern]

Given that a reported error by asan spans multiple bytes, asan may flag the error as an unknown-crash instead of the appropriate error name.

This error can be reproduced via a partial buffer overflow (on gcc), which reports unknown-crash instead of stack-buffer-overflow for the below:

https://godbolt.org/z/abrjrvnzj

# minimal reprod (should occur on gcc-7 - gcc-15, x86_64)
#
# gcc -fsanitize=address reprod.c

struct X {
    char bytes[16];
};

__attribute__((noinline)) struct X out_of_bounds() {
    volatile char bytes[16];
    struct X* x_ptr = (struct X*)(bytes + 2);
    return *x_ptr;
}

int main() {
    struct X x = out_of_bounds();
    return x.bytes[0];
}

This is due to a flawed heuristic in asan_errors.cpp, which won't always locate the appropriate shadow byte that would indicate a corresponding error. This can happen for any reported errors which span either:

• exactly 8 bytes, or
• 16 and more bytes.

The above example doesn't reproduce the issue on clang as it reports errors via different pathways:

• gcc-compiled binaries report the starting address and size of the failing read attempt to asan.

• clang-compiled binaries highlight the first byte access that overflows the buffer to asan.

  Note: out-of-scope, but this is also possibly misleading, as it still reports the full size of the read attempt, paired with an address that's not the start of the read.

This behavior appears to be identical for all past versions tested. I'm not aware of a way to replicate this specific issue with clang, though it might have impacted error reporting in other areas.

This patch resolves this issue via a linear scan of applicable shadow bytes (instead of the original heuristic, which, at best, only increments the shadow byte address by 1 for these scenarios).

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

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

Author: Wern (wxwern)

Changes

Given that a reported error by asan spans multiple bytes, asan may flag the error as an unknown-crash instead of the appropriate error name.

This error can be reproduced via a partial buffer overflow (on gcc), which reports unknown-crash instead of stack-buffer-overflow for the below:

https://godbolt.org/z/abrjrvnzj

# minimal reprod (should occur on gcc-7 - gcc-15)
#
# gcc -fsanitize=address reprod.c

struct X {
    char bytes[16];
};

__attribute__((noinline)) struct X out_of_bounds() {
    volatile char bytes[16];
    struct X* x_ptr = (struct X*)(bytes + 2);
    return *x_ptr;
}

int main() {
    struct X x = out_of_bounds();
    return x.bytes[0];
}

This is due to a flawed heuristic in asan_errors.cpp, which won't always locate the appropriate shadow byte that would indicate a corresponding error. This can happen for any reported errors which span either:

• exactly 8 bytes, or
• 16 and more bytes.

The above example doesn't reproduce the issue on clang as it reports errors via different pathways:

• gcc-compiled binaries report the starting address and size of the failing read attempt to asan.

• clang-compiled binaries highlight the first byte access that overflows the buffer to asan.

  Note: out-of-scope, but this is also possibly misleading, as it still reports the full size of the read attempt, paired with an address that's not the start of the read.

This behavior appears to be identical for all past versions tested. I'm not aware of a way to replicate this specific issue with clang, though it might have impacted error reporting in other areas.

This patch resolves this issue via a linear scan of applicable shadow bytes (instead of the original heuristic, which, at best, only increments the shadow byte address by 1 for these scenarios).

---

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

1 Files Affected:

• (modified) compiler-rt/lib/asan/asan_errors.cpp (+5-2)

diff --git a/compiler-rt/lib/asan/asan_errors.cpp b/compiler-rt/lib/asan/asan_errors.cpp
index 2a207cd06ccac..9e109c0895589 100644
--- a/compiler-rt/lib/asan/asan_errors.cpp
+++ b/compiler-rt/lib/asan/asan_errors.cpp
@@ -437,8 +437,11 @@ ErrorGeneric::ErrorGeneric(u32 tid, uptr pc_, uptr bp_, uptr sp_, uptr addr,
     bug_descr = "unknown-crash";
     if (AddrIsInMem(addr)) {
       u8 *shadow_addr = (u8 *)MemToShadow(addr);
-      // If we are accessing 16 bytes, look at the second shadow byte.
-      if (*shadow_addr == 0 && access_size > ASAN_SHADOW_GRANULARITY)
+      u8 *shadow_addr_upper_bound =
+          shadow_addr + (1 + ((access_size - 1) / ASAN_SHADOW_GRANULARITY));
+      // If the read could span multiple shadow bytes,
+      // do a sequential scan and look for the first bad shadow byte.
+      while (*shadow_addr == 0 && shadow_addr < shadow_addr_upper_bound)
         shadow_addr++;
       // If we are in the partial right redzone, look at the next shadow byte.
       if (*shadow_addr > 0 && *shadow_addr < 128) shadow_addr++;

[vitalybuka]

We need a test for that

[vitalybuka]

The above example doesn't reproduce the issue on clang as it reports errors via different pathways:

You can probably trigger that path through ACCESS_MEMORY_RANGE and INTERCEPTORs?

[wxwern]

We need a test for that

The above example doesn't reproduce the issue on clang as it reports errors via different pathways:

You can probably trigger that path through ACCESS_MEMORY_RANGE and INTERCEPTORs?

Thanks, will look into it. I've not written tests yet as I haven't found a way to reproduce this via clang, will do once I can find a reproducible example.