http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011-09-22
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-22
21:39:11 UTC ---
(In reply to comment #1)
> Seems to be caused by PR48571, we throw away the important info (that the
> access was through a.buf1 rather than &a), which is essential for
> -D_FORTIFY_SOURCE=2.
> The change happens already during gimplification:
> - strcpy (&a.buf1[4], D.2732);
> + strcpy (&MEM[(void *)&a + 4B], D.2732);
> while in *.original it was
> strcpy ((char *) &a.buf1 + 4, str1 + 5);
> Not reconstrucing the array ref is fine, but before *.objsz pass we really
> shouldn't throw away the buf1 from it, so it should be tmp = &a.buf1 + 4;
> -D_FORTIFY_SOURCE=2 cares whether the user wrote
> strcpy ((char *) &a + 4, ...); (in which case it allows to overwrite the
> whole object) or strcpy ((char *) &a.buf1 + 4, ...); (in which case it is
> allowed to overwrite just the buf1 field).
>
> Richard, can you please have a look at this?
Sure. Avoiding this during gimplification should be possible - but
preserving &a.buf1 + 4 in some form until objsz will be impossible
I fear. It looks like objsz relies on something that GIMPLE does not
provide.
I'm sure we don't guarantee that any obfuscation of a.buf1 + 4 doesn't
trip on fortify=2, do we?
I suppose the error is in &MEM[(void *)&a + 4B] objsz handling (again).
