[Bug c/112539] New: a struct with an array of unknown size at the end allows writing past end of the struct

[Bug c/112539] New: a struct with an array of unknown size at the end allows writing past end of the struct

[pgmer6809 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539

            Bug ID: 112539
           Summary: a struct with an array of unknown size at the end
                    allows writing past end of the struct
           Product: gcc
           Version: 11.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pgmer6809 at yahoo dot com
  Target Milestone: ---

Created attachment 56590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56590&action=edit
the output of the gcc --save-temps command

See the manpage for sizeof operator at:
https://man7.org/linux/man-pages/man3/offsetof.3.html
it gives an example of code that shows the size of a struct defined as:
          struct s {
               int i;
               char c;
               double d;
               char a[];
           };
           struct s S;
in their sample program (attached?) the output shows that
the offset of a[] is given as 16; the size of the struct is also given as 16.
This is clearly incorrect.
Changing a[] to either simply a, or even a[1] makes the size of the struct 24
bytes which is correct.

I modified their program to actually try writing to locations S.a[0] and S.a[1]
successfully. The code compiles and runs, and even reports the correct values
when I try to print them out.

So (a) is this a bug in the sizeof operator?
(b) could one use the fact that we can write beyond the end of the struct as
the basis for some sort of exploit?

attached is the file with the gcc output from the --save-temps that you want me
to include with the bug report.
The actual output from the screen is below.
Hope this helps.
Regards,
Greg Morse; pgmer6809@yahoo.com
here is the printed output of the program

greg21@trojan:/tmp$ ./a.out
offsets: i=0; c=4; d=8 a=16
sizeof(struct s)=16
sizeof Int  = 4, char=1, double=8, 
The value of S.a is 5A:Z, W 
The address of S is 0x7fff9be5d070 ; The address of S.a is 0x7fff9be5d080 
The address of S.a[0] is 0x7fff9be5d080, and that of S.a[1] is: 0x7fff9be5d081

[Bug c/112539] a struct with an array of unknown size at the end allows writing past end of the struct

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
C99 (and above) have this kind of array called flexible array member.
Which have exactly the semantics you are describing are happening even.

See https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Zero-Length.html were GCC
documents a different extension but references this.

You can also read up about them here:
https://en.cppreference.com/w/c/language/struct

[Bug c/112539] a struct with an array of unknown size at the end allows writing past end of the struct

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539

--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
https://people.kernel.org/kees/bounded-flexible-arrays-in-c and
https://developers.redhat.com/articles/2022/09/29/benefits-limitations-flexible-array-members
are good reads too

[Bug c/112539] a struct with an array of unknown size at the end allows writing past end of the struct

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
This invalid bug report is actually not related to flexible array member.  It's
just invoking an undefined behavior.  With -fsanitize=undefined
-fno-sanitize-recover:

t.c:13:19: runtime error: store to address 0x7ffd20f7fb30 with insufficient
space for an object of type 'char'
0x7ffd20f7fb30: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  00 c7 f6 e9 8f 37 ae d2  68 fc f7 20 fd
7f 00 00  00 00 00 00
              ^ 
In C even

int a[1];
return a[114514];

will compile.  But it triggers an undefined behavior at runtime.  An undefined
behavior may cause a program crash, output some garbage, or "behave as you
expected" if you are lucky.

[Bug c/112539] a struct with an array of unknown size at the end allows writing past end of the struct

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #3)
> This invalid bug report is actually not related to flexible array member. 
> It's just invoking an undefined behavior.  With -fsanitize=undefined
> -fno-sanitize-recover:

Note that the "Enter Bug" page has a red banner referring to 
https://gcc.gnu.org/bugs/, and this page says:

If compiling with -fsanitize=undefined produces any run-time errors, then your
code is probably not correct.

> In C even
> 
> int a[1];
> return a[114514];
> 
> will compile.

Correction: technically it should be "may compile".  The compiler is also
allowed to reject programs which *always* invokes an undefined behavior.  But
AFAIK no C compiler really rejects code because of an OOB array access as at
now.

[Bug c/112539] a struct with an array of unknown size at the end allows writing past end of the struct

[pgmer6809 at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539

--- Comment #5 from Greg Morse <pgmer6809 at yahoo dot com> ---
 Thank you very much for the links.Fascinating stuff for someone who is not a
real programming Guru.I do wonder though what is so appealing about 'trailing
arrays' that they became so embedded in so much code, that the compiler
introduced this undefined behaviour deliberately to accomodate it.But oh well
it probably seemed like a good idea at the time.Thanks again.Greg Morse

    On Tuesday, November 14, 2023 at 11:09:43 p.m. PST, sjames at gcc dot
gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:  

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112539

--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
https://people.kernel.org/kees/bounded-flexible-arrays-in-c and
https://developers.redhat.com/articles/2022/09/29/benefits-limitations-flexible-array-members
are good reads too