[compiler-rt] [ASan] Fix overflow and last byte handling in __asan_region_is_poisoned (PR #183900)

Vitaly Buka via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 3 22:03:38 PST 2026


================
@@ -231,30 +231,40 @@ TEST(AddressSanitizer, ShadowRegionIsPoisonedTest) {
 }
 
 // Test regions fully contained in the last 8 bytes (shadow granularity)
-// before given end address of a memory range (LowMem / MidMem / HighMem).
-// __asan_region_is_poisoned() should not crash for those regions.
-static void TestRegionIsPoisonedNearEnd(uptr end) {
+// of a memory range (LowMem / MidMem / HighMem).
+static void TestIsPoisonedNearMemEnd(uptr end) {
   static const uptr granularity = 1ULL << 3;  // shadow granularity
   for (uptr offset = 0; offset < granularity; ++offset) {
-    uptr ptr = end - offset;
-    for (uptr size = 1; ptr < ptr + size && ptr + size <= end + 1; ++size) {
-      uptr first_poisoned = __asan_region_is_poisoned(ptr, size);
+    const uptr first = end - offset;
+    for (uptr last = first; first <= last && last <= end; ++last) {
+      const uptr size = last - first + 1;
+      // __asan_region_is_poisoned() should not crash for the region.
+      uptr first_poisoned = __asan_region_is_poisoned(first, size);
       EXPECT_TRUE(first_poisoned == 0 ||
-                  (first_poisoned >= ptr && first_poisoned <= ptr + size));
+                  (first_poisoned >= first && first_poisoned <= last))
+          << " first=" << (void*)first << " size=" << size
+          << " first_poisoned=" << (void*)first_poisoned;
+
+      // __asan_region_is_poisoned() and __asan_address_is_poisoned() should
+      // behave consistently, i.e. both should return the same result.
+      if (size == 1) {
+        int is_poisoned = __asan_address_is_poisoned((void*)first);
+        EXPECT_EQ((void*)first_poisoned, is_poisoned ? (void*)first : 0);
+      }
     }
   }
 }
 
-TEST(AddressSanitizer, IsPoisonedDoesNotCrashOnMemoryBoundaries) {
+TEST(AddressSanitizer, IsPoisonedOnMemoryBoundariesTest) {
----------------
vitalybuka wrote:

can we avoid unncecary rename here?

https://github.com/llvm/llvm-project/pull/183900


More information about the llvm-commits mailing list