Question

a user submitted a bug-report, where my application segfaults in “__fortify_fail()”.

i understand that this is related to building my application with Debian’s “hardening” flags -D_FORTIFY_SOURCE=2 -fstack-protector.

unfortunately the backtrace of the user does not tell me much yet, and the user is not super responsive (right now).

in order to understand better what is going on, i would like to know, what __fortify_fail actually does.

Answer 1

This function is normally just an error reporter. Sample code from glibc is:

extern char **__libc_argv attribute_hidden;

void
__attribute__ ((noreturn))
__fortify_fail (msg)
     const char *msg;
{
  /* The loop is added only to keep gcc happy.  */
  while (1)
    __libc_message (2, "*** %s ***: %s terminated\n",
                    msg, __libc_argv[0] ?: "<unknown>");
}
libc_hidden_def (__fortify_fail)

It may be called here and there where sources is preferred to be fortified. “Fortification” itself is just a couple of run-time checks. Sample usage in openat function from io/openat.c is:

int
__openat_2 (fd, file, oflag)
     int fd;
     const char *file;
     int oflag;
{
  if (oflag & O_CREAT)
    __fortify_fail ("invalid openat call: O_CREAT without mode");

  return __openat (fd, file, oflag);
}

Without fortification, O_CREAT is acceptable without mode (still this case is highly suspicious, it is legal).

Think about __fortify_fail like about printf+abort.

Turning telepathy on about your question, I may suggest that user have some problems with using libc in user code. /lib/x86_64-linux-gnu/libc.so.6(+0xebdf0)[0x7f75d3576df0] is a place inside libc where some runtime-check fails, so pd[0x49b5c0] is a place where libc incorrectly called from.