From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5587 invoked by alias); 23 May 2014 13:51:49 -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 5253 invoked by uid 48); 23 May 2014 13:51:43 -0000 From: "kcc 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 13:51: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: kcc 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/msg02082.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61293 --- Comment #2 from Kostya Serebryany --- (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. > > 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. That's a bit complicated too... > Thus, e.g. tests for this will need to be conditionalized.