This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nis/20987] NIS+ unbounded stack allocations

--- Comment #7 from cvs-commit at gcc dot <cvs-commit at gcc dot> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.24/master has been updated
       via  79c6f51428a9ec977e611e609a8be6aebcb00006 (commit)
      from  7fca94796b67a8ca3730da255e64ee95a818f231 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------;h=79c6f51428a9ec977e611e609a8be6aebcb00006

commit 79c6f51428a9ec977e611e609a8be6aebcb00006
Author: Joseph Myers <>
Date:   Sat Oct 7 13:44:49 2017 +0200

    Fix nss_nisplus build with mainline GCC (bug 20978).

    glibc build with current mainline GCC fails because
    nis/nss_nisplus/nisplus-alias.c contains code

      if (name != NULL)
          *errnop = EINVAL;
          return NSS_STATUS_UNAVAIL;

      char buf[strlen (name) + 9 + tablename_len];

    producing an error about strlen being called on a pointer that is
    always NULL (and a subsequent use of that pointer with a %s format in

    As Andreas noted, the bogus conditional comes from a 1997 change:

    -  if (name == NULL || strlen(name) > 8)
    -    return NSS_STATUS_NOTFOUND;
    -  else
    +  if (name != NULL || strlen(name) <= 8)

    So the intention is clearly to return an error for NULL name.

    This patch duly inverts the sense of the conditional.  It fixes the
    build with GCC mainline, and passes usual glibc testsuite testing for
    x86_64.  However, I have not tried any actual substantive nisplus
    testing, do not have an environment for such testing, and do not know
    whether it is possible that strlen (name) or tablename_len might be
    large so that the VLA for buf is actually a security issue.  However,
    if it is a security issue, there are plenty of other similar instances
    in the nisplus code (that haven't been hidden by a bogus comparison
    with NULL) - and nis_table.c:__create_ib_request uses strdupa on the
    string passed to nis_list, so a local fix in the caller wouldn't
    suffice anyway (see bug 20987).  (Calls to strdupa and other such
    macros that use alloca must be considered equally questionable
    regarding stack overflow issues as direct calls to alloca and VLA

        [BZ #20978]
        * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
        Compare name == NULL, not name != NULL.

    (cherry picked from commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3)


Summary of changes:
 ChangeLog                       |    6 ++++++
 NEWS                            |    1 +
 nis/nss_nisplus/nisplus-alias.c |    2 +-
 3 files changed, 8 insertions(+), 1 deletions(-)

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]