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
next 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: linkBe 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).