From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127807 invoked by alias); 26 Oct 2015 16:57:12 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 127726 invoked by uid 48); 26 Oct 2015 16:57:08 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved. Date: Mon, 26 Oct 2015 16:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: WONTFIX X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-10/txt/msg02152.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016 --- Comment #6 from Jakub Jelinek --- (In reply to Reid Kleckner from comment #5) > (In reply to Maxim Ostapenko from comment #4) > > This happens because in LLVM case ASan changes symbols size ('f' in our > > case) and just breaks ABI for the library. Relinking binary each time we > > replace non-sanitized library with sanitized one is undesirable for large > > package oriented systems (e.g. distributives), so we need a general solution > > for the problem. > > Can you elaborate as to why changing the size of a visible global in a > shared lib is an ABI break with ELF? That's surprising to me, and my > searches haven't helped me understand. 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) 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