public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "pgmer6809 at yahoo dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/112539] New: a struct with an array of unknown size at the end allows writing past end of the struct
Date: Wed, 15 Nov 2023 07:01:53 +0000	[thread overview]
Message-ID: <bug-112539-4@http.gcc.gnu.org/bugzilla/> (raw)

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

             reply	other threads:[~2023-11-15  7:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-15  7:01 pgmer6809 at yahoo dot com [this message]
2023-11-15  7:08 ` [Bug c/112539] " pinskia at gcc dot gnu.org
2023-11-15  7:09 ` sjames at gcc dot gnu.org
2023-11-15  9:34 ` xry111 at gcc dot gnu.org
2023-11-15  9:39 ` xry111 at gcc dot gnu.org
2023-11-15 22:40 ` pgmer6809 at yahoo dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-112539-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).