ACCESS_MEMORY_RANGE defined in asan_interceptors_memintrinsics.hreports the poisoned address (__bad), instead of the start address(__offset) during a memory access to ReportGenericError.We can determine that the latter (__offset) is the intendedinterpretation, as most error descriptions are decided by treatingthe given address as a start address (for example, see:PrintAccessAndVarIntersection in asan_descriptions.cpp, whichdecides whether a variable underflows or overflows dependingon the given addr and access_size).GCC also uses the latter interpretation. For instance, in bufferoverflows, it appears to do its own processing, and will reportthe start address of an overflowing read to ASan. This is incontrast to Clang, which uses __asan_memcpy directly.This patch fixes the above issue.Existing tests previously assumed and check for the former incorrectbehaviour. The error descriptions in those tests have thus beencorrected.

Given that a reported error by ASan spans multiple bytes, ASan mayflag the error as an 'unknown-crash' instead of the appropriate errorname.This error can be reproduced via a partial buffer overflow (any GCC,or after performing the patch in the previous commit to Clang).They'll report 'unknown-crash' instead of 'stack-buffer-overflow'for the below:    # minimal reprod    #https://godbolt.org/z/abrjrvnzj    #    # 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'talways locate the appropriate shadow byte that would indicate acorresponding error. This can happen for any reported errors whichspan either: exactly 8 bytes, or 16 and more bytes.This bug was previously hidden from Clang (but has always been presentin GCC) until the previous commit's fix on address reporting.Specifically, ACCESS_MEMORY_RANGE in ASan previously reports the firstpoisoned byte (instead of the start address, like in GCC). This maskedthe above bug from occuring, as it coincidentally guarantees theheuristic will always work, with slightly inaccurate reports.This patch resolves this issue via a linear scan of applicableshadow bytes (instead of the original heuristic, which, at best, onlyincrements the shadow byte address by 1 for these scenarios).