This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/59258] usan: ICE(segfault): stack-buffer-overflow with -fsanitize=undefined
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 23 Nov 2013 21:46:44 +0000
- Subject: [Bug sanitizer/59258] usan: ICE(segfault): stack-buffer-overflow with -fsanitize=undefined
- Auto-submitted: auto-generated
- References: <bug-59258-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59258
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #3)
> Why? We are already checking that nelts is < 3. See the
> gcc_checking_assert above.
Well, at least to me it is not obvious whether it can get larger.
size_t i = 0;
if (loc != UNKNOWN_LOCATION)
i++
for (t = va_arg (args, tree); t != NULL_TREE;
i++, t = va_arg (args, tree))
gcc_checking_assert (i < 3);
vec_safe_push (saved_args, t);
Thus, saved_args probably has 0, 1 or 2 entries but with loc ==
UNKNOWN_LOCATION it could have 3.
if (mismatch != NULL)
i++;
for (i = 0; i < nelts; i++)
t = (*saved_args)[i];
If mismatch != NULL, (number of saved_args) == 2 and loc != UNKNOWN_LOCATION,
one has: 1+1+2*2 = 6 array elements, but only space for 5; with loc ==
UNKNOWN_LOCATION one could even have 0+1+2*(3) = 7.
I don't find it obvious that 5 is sufficient, even if closer inspection will
shows that this is always the case.