This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016

--- Comment #7 from Reid Kleckner <rnk at google dot com> ---
(In reply to Jakub Jelinek from comment #6)
> Because symbol size is part of the ABI, and LLVM emits different symbol size
> between -fsanitize=address and -fno-sanitize=address.
> E.g. COPY relocations use the st_size field, so you can have:
> 1) shared library originally not ASAN instrumented, binary (e.g. non-ASAN)
> linked against it, then the shared library recompiled with ASAN - the size
> of the symbol in the binary will be the one without padding, but LLVM
> incorrectly registers the variable using global symbol rather than local
> alias and thus assumes there is padding which is not available (plus you can
> get a runtime warning on the st_size mismatch from the dynamic linker)

I thought COPY relocations only occurred with fPIE, but I must have been
mistaken.

> 2) even without COPY relocations, you could have the same variable defined
> in multiple shared libraries, if some of them are -fsanitize=address and the
> others are not, there is mismatch between the variable sizes, and depending
> on which library comes earlier in the symbol search scope, you could have
> either the version without or with padding used at runtime, but the
> sanitized libraries could very well register the non-padded one, making it
> fatal error to access e.g. variables after it

LLVM ASan tries to instrument only global definitions with external linkage.
The goal of this check is to ensure that we have found the one true definition
of the global, and it isn't COMDAT, weak, a C string, or going to get replaced
with something else at link time through some other means.

It seems like you are describing interposition, which isn't something LLVM
supports very well. LLVM has no equivalent of -fsemantic-interposition, for
example. We always operate under something like -fno-semantic-interposition. (I
know, it's ironic, because ASan interposes libc.)

Anyway, I agree the COPY relocation issue is a real problem, but other than
that I think our approach is at least internally consistent.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]