public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nss/26038] New: [core_dump] call getpwnam_r() appears core_dump
@ 2020-05-25  9:25 liaichun at huawei dot com
  2020-05-25  9:33 ` [Bug nss/26038] " liaichun at huawei dot com
                   ` (13 more replies)
  0 siblings, 14 replies; 15+ messages in thread
From: liaichun at huawei dot com @ 2020-05-25  9:25 UTC (permalink / raw)
  To: glibc-bugs

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

            Bug ID: 26038
           Summary: [core_dump] call getpwnam_r() appears core_dump
           Product: glibc
           Version: 2.31
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: nss
          Assignee: unassigned at sourceware dot org
          Reporter: liaichun at huawei dot com
  Target Milestone: ---

When I repeatedly call getpwnam_r (), there will be a small probability of
coredump. I analyze the cause of the problem，please see the description below.

nss/getXXbyYY_r.c

libc_hidden_proto (DB_LOOKUP_FCT)
int
INTERNAL (REENTRANT_NAME) (ADD_PARAMS, LOOKUP_TYPE *resbuf, char *buffer,
                           size_t buflen, LOOKUP_TYPE **result H_ERRNO_PARM
                           EXTRA_PARAMS)
{
   ......
   static bool startp_initialized;
   static lookup_function start_fct;
   union
  {
    lookup_function l;
    void *ptr;
  } fct;
  ......
  if (! startp_initialized)
    {
      no_more = DB_LOOKUP_FCT (&nip, REENTRANT_NAME_STRING,
                               REENTRANT2_NAME_STRING, &fct.ptr);
      if (no_more)     /* first init, if no_more, start_fct would always 0x0 */
        {
         /* do something */  
        }
      else
        {
          void *tmp_ptr = fct.l;
          start_fct = tmp_ptr;
          /* do something */
        }
      atomic_write_barrier ();
      startp_initialized = true;
   }
  else
    {
      fct.l = start_fct;   /* if first no_more, start_fct is 0x0, fct.l would
be always 0x0. */ 
      nip = startp;

      no_more = nip == (service_user *) -1l;
    }
  ......
  while (no_more == 0)
    {
#ifdef NEED_H_ERRNO
      any_service = true;
#endif
      status = DL_CALL_FCT (fct.l, (ADD_VARIABLES, resbuf, buffer, buflen,
                                    &errno H_ERRNO_VAR EXTRA_VARIABLES));
    /* fct.l is 0x0, and here call function fct.1 would core dump */
  ......
}

1、when first call DB_LOOKUP_FCT() return -1, startp_initialized would be true,
but start_fct stil is 0x0， and would never change.
2、Once start_fct is 0x0, fct.l would be always 0x0 n matter how many times
getpwnam_r() is called.
3、if fct.l is 0x0, the next call DL_CALL_FCT(fct.l,xxx) would cause core_dump.

==============================================================================
I think if first startp_initialized err, next should call DB_LOOKUP_FCT()
again, util successfully get, and only then is the initialization successful.

libc_hidden_proto (DB_LOOKUP_FCT)
int
INTERNAL (REENTRANT_NAME) (ADD_PARAMS, LOOKUP_TYPE *resbuf, char *buffer,
                           size_t buflen, LOOKUP_TYPE **result H_ERRNO_PARM
                           EXTRA_PARAMS)
{
   ......
   static bool startp_initialized;
   static lookup_function start_fct;
   union
  {
    lookup_function l;
    void *ptr;
  } fct;
  ......
  if (! startp_initialized)
    {
      no_more = DB_LOOKUP_FCT (&nip, REENTRANT_NAME_STRING,
                               REENTRANT2_NAME_STRING, &fct.ptr);
      if (no_more)     
        {
-         void *tmp_ptr = (service_user *) -1l;
-#ifdef PTR_MANGLE
-         PTR_MANGLE (tmp_ptr);
-#endif
-         startp = tmp_ptr;
+#ifdef NEED_H_ERRNO
+       *h_errnop = NETDB_INTERNAL;
+#endif
+       *result = NULL;
+       return errno;
        }
      else
        {
          void *tmp_ptr = fct.l;
          start_fct = tmp_ptr;
          /* do something */
        }
      atomic_write_barrier ();
      startp_initialized = true;
   }

  ......
}

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

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-08-10 12:55 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-25  9:25 [Bug nss/26038] New: [core_dump] call getpwnam_r() appears core_dump liaichun at huawei dot com
2020-05-25  9:33 ` [Bug nss/26038] " liaichun at huawei dot com
2020-05-25  9:42 ` schwab@linux-m68k.org
2020-05-25  9:46 ` liaichun at huawei dot com
2020-05-25  9:52 ` schwab@linux-m68k.org
2020-05-25 10:00 ` liaichun at huawei dot com
2020-05-25 10:06 ` schwab@linux-m68k.org
2020-05-25 11:25 ` liaichun at huawei dot com
2020-05-25 12:20 ` schwab@linux-m68k.org
2020-05-25 12:29 ` schwab@linux-m68k.org
2020-06-09  8:29 ` liaichun at huawei dot com
2020-06-09  8:57 ` schwab@linux-m68k.org
2020-06-09  9:43 ` liaichun at huawei dot com
2020-08-05 13:57 ` liaichun at huawei dot com
2020-08-10 12:55 ` liaichun at huawei dot com

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).