https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78498
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-11-28
Ever confirmed|0 |1
--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Confirmed.
I don't think it's a dup of bug 78324, though.
c-format.c gets the line via input.c, then has:
3345 Generate a trimmed copy, containing the prefix part of the
conversion
3346 specification, up to the (but not including) the length modifier.
3347 In the above example, this would be "%-+*.*". */
3348 const char *current_content = line + start.column - 1;
3349 int length_up_to_type = caret.column - start.column;
3350 char *prefix = xstrndup (current_content, length_up_to_type);
leading to a call to xstrndup.
xstrndup has:
47 char *
48 xstrndup (const char *s, size_t n)
49 {
50 char *result;
51 size_t len = strlen (s);
52
53 if (n < len)
54 len = n;
The uninit read happens within the call to strlen at line 51.
I was surprised to see that strlen within xstrndup; I was expecting it to
simply use "n".
input.c doesn't zero-terminate the strings fed in, so presumably that strlen
call is reading arbitrary data past the end of the allocation until it hits a
zero - but then the result is ignored, since the conditional at line 53 will
always hold.
