public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/48916] New: Falsely reported buffer overrun due to incorrect __builtin_object_size.
@ 2011-05-06 11:43 jkb at sanger dot ac.uk
  2011-05-06 12:28 ` [Bug c/48916] " jakub at gcc dot gnu.org
  0 siblings, 1 reply; 2+ messages in thread
From: jkb at sanger dot ac.uk @ 2011-05-06 11:43 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48916

           Summary: Falsely reported buffer overrun due to incorrect
                    __builtin_object_size.
           Product: gcc
           Version: 4.5.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jkb@sanger.ac.uk


Created attachment 24199
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24199
Demonstration of failure for -O -D_FORTIFY_SOURCE=2

I have a case where __builtin_object_size() appears to return an incorrect
value (1), causing strcpy when used under -D_FORTIFY_SOURCE=2 to claim a buffer
overrun has been detected.

We allocate a block of memory sufficiently large to hold both a structure and a
string immediately following it. The structure holds a pointer to this string
and, for ease of programming, a terminal member whose address will be the start
of the string. An example:

typedef struct {
    char *name;  // == &foo.data
    char data;   // Note: vs char data[], char data[1] or char data[0]
} foo_t;

In this situation, __bos(foo->name) is neither -1 nor is it the correct size.
Instead it appears to be the space remaining up to the end of the structure
rather than up to the end of the malloced block of memory.

More oddly is that only the first call to __builtin_object_size returns a value
while all subsequent calls return -1 instead. This is the primary reason I
suspect this to be a compiler bug rather than simply allowably undefined
behaviour, as we would expect a consistent result.

The error is easily worked around (from a coder's point of view) by changing
the terminal "char data" member to the C99 recommended "char data[]", the prior
GCC equivalent "char data[0]" or even "char data[1]" (which I'd assume to be
identical in behaviour to "char data").

Note that I am unsure of whether this sneaky practice is strictly conforming to
the C standard when not using data[] or data[0], as it means writing to
&foo->data will be performing pointer arithmetic which starts within the struct
and ends up outside of the struct, albeit still within the same malloc heap
element. If it is non-standard, then this may simply fall into the realm of
"undefined behaviour".

The issue was initially discovered using Gentoo-11 with gcc 4.5.2, but has
since been verified as failing on 4.4.4-10.fc13 (Red Hat's patched-
for-Fedora version), 4.5.0, 4.5.2, 4.5.3, and 4.6.0. It works on 4.4.3 and
earlier.

It seems likely the implementation (specifically the non-constant result) of
__builtin_object_size() is the issue. Sorry I do not know if this consistutes
front-end or middle; please update the component as required.

Attached is a program to demonstrate the issue.

James


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug c/48916] Falsely reported buffer overrun due to incorrect __builtin_object_size.
  2011-05-06 11:43 [Bug c/48916] New: Falsely reported buffer overrun due to incorrect __builtin_object_size jkb at sanger dot ac.uk
@ 2011-05-06 12:28 ` jakub at gcc dot gnu.org
  0 siblings, 0 replies; 2+ messages in thread
From: jakub at gcc dot gnu.org @ 2011-05-06 12:28 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48916

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-06 12:01:45 UTC ---
This is invalid with -D_FORTIFY_SOURCE=2, valid with -D_FORTIFY_SOURCE=1.
-D_FORTIFY_SOURCE=2 limits what can be crossed, you can't cross fields except
for a few exceptions (flexible array members and flexible-like array member
constructs).  This one isn't considered flexible-like array member.
Either build with -D_FORITYF_SOURCE=1 instead of =2, or use memcpy instead of
strcpy.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-05-06 12:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-06 11:43 [Bug c/48916] New: Falsely reported buffer overrun due to incorrect __builtin_object_size jkb at sanger dot ac.uk
2011-05-06 12:28 ` [Bug c/48916] " jakub at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).