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/59258] usan: ICE(segfault): stack-buffer-overflow with -fsanitize=undefined


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.


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