public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug build/26789] New: GCC 11 out of bounds access warning calling setjmp and sigsetjmp
@ 2020-10-25 22:16 msebor at gmail dot com
  2020-10-25 22:22 ` [Bug build/26789] " schwab@linux-m68k.org
  0 siblings, 1 reply; 2+ messages in thread
From: msebor at gmail dot com @ 2020-10-25 22:16 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=26789

            Bug ID: 26789
           Summary: GCC 11 out of bounds access warning calling setjmp and
                    sigsetjmp
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: msebor at gmail dot com
                CC: carlos at redhat dot com
  Target Milestone: ---

Building (and using) Glibc with GCC 11 triggers warnings like the one below for
calls to setjmp() and sigsetjmp():

In file included from ../include/setjmp.h:2,
                 from ../nptl/descr.h:24,
                 from ../sysdeps/x86_64/nptl/tls.h:130,
                 from ../include/link.h:51,
                 from ../include/dlfcn.h:4,
                 from ../sysdeps/generic/ldsodefs.h:32,
                 from ../sysdeps/x86/ldsodefs.h:65,
                 from ../sysdeps/gnu/ldsodefs.h:46,
                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
                 from ../sysdeps/x86/libc-start.c:22:
../csu/libc-start.c: In function ‘__libc_start_main’:
../setjmp/setjmp.h:49:25: warning: ‘_setjmp’ accessing 200 bytes in a region of
size 72 [-Wstringop-overflow=]
   49 | #define setjmp(env)     _setjmp (env)
      |                         ^~~~~~~~~~~~~
../csu/libc-start.c:301:20: note: in expansion of macro ‘setjmp’
  301 |   not_first_call = setjmp ((struct __jmp_buf_tag *)
unwind_buf.cancel_jmp_buf);
      |                    ^~~~~~
../setjmp/setjmp.h:49:25: note: referencing argument 1 of type ‘struct
__jmp_buf_tag *’
   49 | #define setjmp(env)     _setjmp (env)
      |                         ^~~~~~~~~~~~~
../csu/libc-start.c:301:20: note: in expansion of macro ‘setjmp’
  301 |   not_first_call = setjmp ((struct __jmp_buf_tag *)
unwind_buf.cancel_jmp_buf);
      |                    ^~~~~~
In file included from <command-line>:
../include/setjmp.h:27:20: note: in a call to function ‘_setjmp’
   27 | libc_hidden_proto (_setjmp)
      |                    ^~~~~~~
./../include/libc-symbols.h:605:33: note: in definition of macro
‘__hidden_proto’
  605 |   extern thread __typeof (name) name __hidden_proto_hiddenattr (attrs);
      |                                 ^~~~
./../include/libc-symbols.h:624:44: note: in expansion of macro ‘hidden_proto’
  624 | # define libc_hidden_proto(name, attrs...) hidden_proto (name, ##attrs)
      |                                            ^~~~~~~~~~~~
../include/setjmp.h:27:1: note: in expansion of macro ‘libc_hidden_proto’
   27 | libc_hidden_proto (_setjmp)
      | ^~~~~~~~~~~~~~~~~


The problem seems to be caused by the following declarations:

typedef long int __jmp_buf[8];   // 64 bytes

typedef struct
{
  struct
  {
    __jmp_buf __cancel_jmp_buf;   // 64 bytes
    int __mask_was_saved;         // 4 bytes
  } __cancel_jmp_buf[1];          // 72 bytes (68 + 4 padding)
  void *__pad[4];
} __pthread_unwind_buf_t __attribute__ ((__aligned__));

typedef struct
{
  unsigned long int __val[(1024 / (8 * sizeof (unsigned long int)))];
} __sigset_t;                     // 128 bytes

struct __jmp_buf_tag              // 200 bytes (196 + 4 padding)
  {
    __jmp_buf __jmpbuf;           // 64 bytes
    int __mask_was_saved;         // 4 bytes
    __sigset_t __saved_mask;      // 128 bytes
  };

extern int _setjmp (struct __jmp_buf_tag __env[1]) __attribute__
((__nothrow__));

and calls like the one below:

   ... _setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf);

_setjmp() is declared to take an array of at least one __jmp_buf_tag element,
and unwind_buf.cancel_jmp_buf is an array of a single element of the unnamed
struct in __pthread_unwind_buf_t.  __jmp_buf_tag is a much larger type than the
unnamed struct, so the warning is justified.

I'm sure the code must be safe so perhaps the way to avoid the warning is to
change the declaration of setjmp() to take a pointer to long instead.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

* [Bug build/26789] GCC 11 out of bounds access warning calling setjmp and sigsetjmp
  2020-10-25 22:16 [Bug build/26789] New: GCC 11 out of bounds access warning calling setjmp and sigsetjmp msebor at gmail dot com
@ 2020-10-25 22:22 ` schwab@linux-m68k.org
  0 siblings, 0 replies; 2+ messages in thread
From: schwab@linux-m68k.org @ 2020-10-25 22:22 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=26789

Andreas Schwab <schwab@linux-m68k.org> changed:

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
That's false positive.

*** This bug has been marked as a duplicate of bug 26647 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

end of thread, other threads:[~2020-10-25 22:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-25 22:16 [Bug build/26789] New: GCC 11 out of bounds access warning calling setjmp and sigsetjmp msebor at gmail dot com
2020-10-25 22:22 ` [Bug build/26789] " schwab@linux-m68k.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).