From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25543 invoked by alias); 23 May 2014 14:14:15 -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 25485 invoked by uid 48); 23 May 2014 14:14:11 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/61293] asan can not find left buffer overflow of new[]-allocated buffer, frontend help needed Date: Fri, 23 May 2014 14:14: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: 4.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: 2014-05/txt/msg02083.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61293 --- Comment #3 from Jakub Jelinek --- (In reply to Kostya Serebryany from comment #2) > (In reply to Jakub Jelinek from comment #1) > > IMNSHO you can't change the value of extra, that is an ABI issue, > > and -fsanitize=address shouldn't be an ABI changing option. Consider: > > struct S { S (); ~S (); }; > > S *foo (int n) { return new S[n]; } > > void bar (S *p) { delete [] p; } > > int main () { bar (foo (5)); } > > where bar is defined in a different compilation unit/library and something > > is built with -fsanitize=address, something is not. > > > > If the padding before structure is at least 64-bit, sure, instrumenting the > > FE to put there an __asan_poison_memory_region call after the size is stored > > yep > > > there > > and in delete[] again to __asan_unpoison_memory_region before reading the > > size should not be that hard. > > Yes, but a bit more preferable is to ignore the instructions > reading the size instead of calling __asan_unpoison_memory_region. > Consider a case where the DTORs are accessing the array itself out of bounds. > (We've seen similar things!!) > That's a bit harder to implement though. Yeah, that makes it uglier, supposedly easiest (in GCC) would be to replace the memory store to the area before the returned pointer with some magic builtin user can't normally use, ditto for the load and add another builtin right before the actual operator delete call, assign a new 0xeN? shadow value for "the area before operator new", and in asan pass just expand those calls to more code (the first one to a normal 0 check of shadow plus memory store, followed by manually poisioning the shadow with the new magic constant, the second one which would check if the shadow at that point is either 0 or the 0xeN? magic value, otherwise die, then load, and finally the last builtin that would unpoison it. > > For 32-bit code if the type doesn't need at least 64-bit alignment (again, > > alignment of the type is an ABI thing), you are out of luck I'm afraid. > Yea... We can theoretically request operator new to > return memory that is == 4 mod 8 for these cases. No, because you don't know when some type that will actually need 64-bit alignment is used. Because if you misalign the returned value, then such types would not be aligned properly.