Patches for glibc to compile with GCC7

Signed-off-by: Alexey Neyman <stilor@att.net>

patches/glibc/2.12.1/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.12.1/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.12.2/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.12.2/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.13/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.13/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.14.1/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.14.1/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.14/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.14/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.15/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.15/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.16.0/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.16.0/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.17/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.17/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.18/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.18/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.19/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.19/930-explicit-boolean.patch

@@ -0,0 +1,33 @@
+commit e223d1fe72e820d96f43831412ab267a1ace04d0
+Author: steve ellcey-CA Eng-Software <sellcey@sellcey-thinkpad.caveonetworks.com>
+Date:   Fri Oct 14 12:53:27 2016 -0700
+
+    Fix warnings from latest GCC.
+    
+            * sysdeps/ieee754/dbl-64/e_pow.c (checkint) Make conditions explicitly
+            boolean.
+
+diff --git a/sysdeps/ieee754/dbl-64/e_pow.c b/sysdeps/ieee754/dbl-64/e_pow.c
+index 663fa392c2..bd758b5979 100644
+--- a/sysdeps/ieee754/dbl-64/e_pow.c
++++ b/sysdeps/ieee754/dbl-64/e_pow.c
+@@ -466,15 +466,15 @@ checkint (double x)
+     return (n & 1) ? -1 : 1;	/* odd or even */
+   if (k > 20)
+     {
+-      if (n << (k - 20))
++      if (n << (k - 20) != 0)
+ 	return 0;		/* if not integer */
+-      return (n << (k - 21)) ? -1 : 1;
++      return (n << (k - 21) != 0) ? -1 : 1;
+     }
+   if (n)
+     return 0;			/*if  not integer */
+   if (k == 20)
+     return (m & 1) ? -1 : 1;
+-  if (m << (k + 12))
++  if (m << (k + 12) != 0)
+     return 0;
+-  return (m << (k + 11)) ? -1 : 1;
++  return (m << (k + 11) != 0) ? -1 : 1;
+ }

patches/glibc/2.19/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.20/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.20/930-explicit-boolean.patch

@@ -0,0 +1,33 @@
+commit e223d1fe72e820d96f43831412ab267a1ace04d0
+Author: steve ellcey-CA Eng-Software <sellcey@sellcey-thinkpad.caveonetworks.com>
+Date:   Fri Oct 14 12:53:27 2016 -0700
+
+    Fix warnings from latest GCC.
+    
+            * sysdeps/ieee754/dbl-64/e_pow.c (checkint) Make conditions explicitly
+            boolean.
+
+diff --git a/sysdeps/ieee754/dbl-64/e_pow.c b/sysdeps/ieee754/dbl-64/e_pow.c
+index 663fa392c2..bd758b5979 100644
+--- a/sysdeps/ieee754/dbl-64/e_pow.c
++++ b/sysdeps/ieee754/dbl-64/e_pow.c
+@@ -466,15 +466,15 @@ checkint (double x)
+     return (n & 1) ? -1 : 1;	/* odd or even */
+   if (k > 20)
+     {
+-      if (n << (k - 20))
++      if (n << (k - 20) != 0)
+ 	return 0;		/* if not integer */
+-      return (n << (k - 21)) ? -1 : 1;
++      return (n << (k - 21) != 0) ? -1 : 1;
+     }
+   if (n)
+     return 0;			/*if  not integer */
+   if (k == 20)
+     return (m & 1) ? -1 : 1;
+-  if (m << (k + 12))
++  if (m << (k + 12) != 0)
+     return 0;
+-  return (m << (k + 11)) ? -1 : 1;
++  return (m << (k + 11) != 0) ? -1 : 1;
+ }

patches/glibc/2.20/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.21/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.21/930-explicit-boolean.patch

@@ -0,0 +1,33 @@
+commit e223d1fe72e820d96f43831412ab267a1ace04d0
+Author: steve ellcey-CA Eng-Software <sellcey@sellcey-thinkpad.caveonetworks.com>
+Date:   Fri Oct 14 12:53:27 2016 -0700
+
+    Fix warnings from latest GCC.
+    
+            * sysdeps/ieee754/dbl-64/e_pow.c (checkint) Make conditions explicitly
+            boolean.
+
+diff --git a/sysdeps/ieee754/dbl-64/e_pow.c b/sysdeps/ieee754/dbl-64/e_pow.c
+index 663fa392c2..bd758b5979 100644
+--- a/sysdeps/ieee754/dbl-64/e_pow.c
++++ b/sysdeps/ieee754/dbl-64/e_pow.c
+@@ -466,15 +466,15 @@ checkint (double x)
+     return (n & 1) ? -1 : 1;	/* odd or even */
+   if (k > 20)
+     {
+-      if (n << (k - 20))
++      if (n << (k - 20) != 0)
+ 	return 0;		/* if not integer */
+-      return (n << (k - 21)) ? -1 : 1;
++      return (n << (k - 21) != 0) ? -1 : 1;
+     }
+   if (n)
+     return 0;			/*if  not integer */
+   if (k == 20)
+     return (m & 1) ? -1 : 1;
+-  if (m << (k + 12))
++  if (m << (k + 12) != 0)
+     return 0;
+-  return (m << (k + 11)) ? -1 : 1;
++  return (m << (k + 11) != 0) ? -1 : 1;
+ }

patches/glibc/2.21/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.21/950-dlclose-assert.patch

@@ -0,0 +1,40 @@
+commit 2bd2cad9e8a410643e80efa0b15f6f2882e1271b
+Author: Roland McGrath <roland@hack.frob.com>
+Date:   Fri Apr 17 14:29:40 2015 -0700
+
+    Avoid confusing compiler with dynamically impossible statically invalid dereference in _dl_close_worker.
+
+diff --git a/elf/dl-close.c b/elf/dl-close.c
+index cf8f9e0465..412f71d70b 100644
+--- a/elf/dl-close.c
++++ b/elf/dl-close.c
+@@ -641,9 +641,16 @@ _dl_close_worker (struct link_map *map)
+ 	  DL_UNMAP (imap);
+ 
+ 	  /* Finally, unlink the data structure and free it.  */
+-	  if (imap->l_prev != NULL)
+-	    imap->l_prev->l_next = imap->l_next;
+-	  else
++#if DL_NNS == 1
++	  /* The assert in the (imap->l_prev == NULL) case gives
++	     the compiler license to warn that NS points outside
++	     the dl_ns array bounds in that case (as nsid != LM_ID_BASE
++	     is tantamount to nsid >= DL_NNS).  That should be impossible
++	     in this configuration, so just assert about it instead.  */
++	  assert (nsid == LM_ID_BASE);
++	  assert (imap->l_prev != NULL);
++#else
++	  if (imap->l_prev == NULL)
+ 	    {
+ 	      assert (nsid != LM_ID_BASE);
+ 	      ns->_ns_loaded = imap->l_next;
+@@ -652,6 +659,9 @@ _dl_close_worker (struct link_map *map)
+ 		 we leave for debuggers to examine.  */
+ 	      r->r_map = (void *) ns->_ns_loaded;
+ 	    }
++	  else
++#endif
++	    imap->l_prev->l_next = imap->l_next;
+ 
+ 	  --ns->_ns_nloaded;
+ 	  if (imap->l_next != NULL)

patches/glibc/2.22/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.22/930-explicit-boolean.patch

@@ -0,0 +1,33 @@
+commit e223d1fe72e820d96f43831412ab267a1ace04d0
+Author: steve ellcey-CA Eng-Software <sellcey@sellcey-thinkpad.caveonetworks.com>
+Date:   Fri Oct 14 12:53:27 2016 -0700
+
+    Fix warnings from latest GCC.
+    
+            * sysdeps/ieee754/dbl-64/e_pow.c (checkint) Make conditions explicitly
+            boolean.
+
+diff --git a/sysdeps/ieee754/dbl-64/e_pow.c b/sysdeps/ieee754/dbl-64/e_pow.c
+index 663fa392c2..bd758b5979 100644
+--- a/sysdeps/ieee754/dbl-64/e_pow.c
++++ b/sysdeps/ieee754/dbl-64/e_pow.c
+@@ -466,15 +466,15 @@ checkint (double x)
+     return (n & 1) ? -1 : 1;	/* odd or even */
+   if (k > 20)
+     {
+-      if (n << (k - 20))
++      if (n << (k - 20) != 0)
+ 	return 0;		/* if not integer */
+-      return (n << (k - 21)) ? -1 : 1;
++      return (n << (k - 21) != 0) ? -1 : 1;
+     }
+   if (n)
+     return 0;			/*if  not integer */
+   if (k == 20)
+     return (m & 1) ? -1 : 1;
+-  if (m << (k + 12))
++  if (m << (k + 12) != 0)
+     return 0;
+-  return (m << (k + 11)) ? -1 : 1;
++  return (m << (k + 11) != 0) ? -1 : 1;
+ }

patches/glibc/2.22/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.23/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.23/930-explicit-boolean.patch

@@ -0,0 +1,33 @@
+commit e223d1fe72e820d96f43831412ab267a1ace04d0
+Author: steve ellcey-CA Eng-Software <sellcey@sellcey-thinkpad.caveonetworks.com>
+Date:   Fri Oct 14 12:53:27 2016 -0700
+
+    Fix warnings from latest GCC.
+    
+            * sysdeps/ieee754/dbl-64/e_pow.c (checkint) Make conditions explicitly
+            boolean.
+
+diff --git a/sysdeps/ieee754/dbl-64/e_pow.c b/sysdeps/ieee754/dbl-64/e_pow.c
+index 663fa392c2..bd758b5979 100644
+--- a/sysdeps/ieee754/dbl-64/e_pow.c
++++ b/sysdeps/ieee754/dbl-64/e_pow.c
+@@ -466,15 +466,15 @@ checkint (double x)
+     return (n & 1) ? -1 : 1;	/* odd or even */
+   if (k > 20)
+     {
+-      if (n << (k - 20))
++      if (n << (k - 20) != 0)
+ 	return 0;		/* if not integer */
+-      return (n << (k - 21)) ? -1 : 1;
++      return (n << (k - 21) != 0) ? -1 : 1;
+     }
+   if (n)
+     return 0;			/*if  not integer */
+   if (k == 20)
+     return (m & 1) ? -1 : 1;
+-  if (m << (k + 12))
++  if (m << (k + 12) != 0)
+     return 0;
+-  return (m << (k + 11)) ? -1 : 1;
++  return (m << (k + 11) != 0) ? -1 : 1;
+ }

patches/glibc/2.23/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/2.24/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/2.24/930-explicit-boolean.patch

@@ -0,0 +1,33 @@
+commit e223d1fe72e820d96f43831412ab267a1ace04d0
+Author: steve ellcey-CA Eng-Software <sellcey@sellcey-thinkpad.caveonetworks.com>
+Date:   Fri Oct 14 12:53:27 2016 -0700
+
+    Fix warnings from latest GCC.
+    
+            * sysdeps/ieee754/dbl-64/e_pow.c (checkint) Make conditions explicitly
+            boolean.
+
+diff --git a/sysdeps/ieee754/dbl-64/e_pow.c b/sysdeps/ieee754/dbl-64/e_pow.c
+index 663fa392c2..bd758b5979 100644
+--- a/sysdeps/ieee754/dbl-64/e_pow.c
++++ b/sysdeps/ieee754/dbl-64/e_pow.c
+@@ -466,15 +466,15 @@ checkint (double x)
+     return (n & 1) ? -1 : 1;	/* odd or even */
+   if (k > 20)
+     {
+-      if (n << (k - 20))
++      if (n << (k - 20) != 0)
+ 	return 0;		/* if not integer */
+-      return (n << (k - 21)) ? -1 : 1;
++      return (n << (k - 21) != 0) ? -1 : 1;
+     }
+   if (n)
+     return 0;			/*if  not integer */
+   if (k == 20)
+     return (m & 1) ? -1 : 1;
+-  if (m << (k + 12))
++  if (m << (k + 12) != 0)
+     return 0;
+-  return (m << (k + 11)) ? -1 : 1;
++  return (m << (k + 11) != 0) ? -1 : 1;
+ }

patches/glibc/2.24/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;

patches/glibc/linaro-2.20-2014.11/920-fix-rpc_parse-format.patch

@@ -0,0 +1,60 @@
+commit 5874510faaf3cbd0bb112aaacab9f225002beed1
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Tue Nov 8 23:44:51 2016 +0000
+
+    Fix rpcgen buffer overrun (bug 20790).
+    
+    Building with GCC 7 produces an error building rpcgen:
+    
+    rpc_parse.c: In function 'get_prog_declaration':
+    rpc_parse.c:543:25: error: may write a terminating nul past the end of the destination [-Werror=format-length=]
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+                         ~~~~^
+    rpc_parse.c:543:5: note: format output between 5 and 14 bytes into a destination of size 10
+         sprintf (name, "%s%d", ARGNAME, num); /* default name of argument */
+         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+    
+    That buffer overrun is for the case where the .x file declares a
+    program with a million arguments.  The strcpy two lines above can
+    generate a buffer overrun much more simply for a long argument name.
+    
+    The limit on length of line read by rpcgen (MAXLINESIZE == 1024)
+    provides a bound on the buffer size needed, so this patch just changes
+    the buffer size to MAXLINESIZE to avoid both possible buffer
+    overruns.  A testcase is added that rpcgen does not crash with a
+    500-character argument name, where it previously crashed.
+    
+    It would not at all surprise me if there are many other ways of
+    crashing rpcgen with either valid or invalid input; fuzz testing would
+    likely find various such bugs, though I don't think they are that
+    important to fix (rpcgen is not that likely to be used with untrusted
+    .x files as input).  (As well as fuzz-findable bugs there are probably
+    also issues when various int variables get overflowed on very large
+    input.)  The test infrastructure for rpcgen-not-crashing tests would
+    need extending if tests are to be added for cases where rpcgen should
+    produce an error, as opposed to cases where it should succeed.
+    
+    Tested for x86_64 and x86.
+    
+            [BZ #20790]
+            * sunrpc/rpc_parse.c (get_prog_declaration): Increase buffer size
+            to MAXLINESIZE.
+            * sunrpc/bug20790.x: New file.
+            * sunrpc/Makefile [$(run-built-tests) = yes] (rpcgen-tests): New
+            variable.
+            [$(run-built-tests) = yes] (tests-special): Add $(rpcgen-tests).
+            [$(run-built-tests) = yes] ($(rpcgen-tests)): New rule.
+
+diff --git a/sunrpc/rpc_parse.c b/sunrpc/rpc_parse.c
+index 1a1df6d8c2..505a6554cf 100644
+--- a/sunrpc/rpc_parse.c
++++ b/sunrpc/rpc_parse.c
+@@ -521,7 +521,7 @@ static void
+ get_prog_declaration (declaration * dec, defkind dkind, int num /* arg number */ )
+ {
+   token tok;
+-  char name[10];		/* argument name */
++  char name[MAXLINESIZE];		/* argument name */
+ 
+   if (dkind == DEF_PROGRAM)
+     {

patches/glibc/linaro-2.20-2014.11/930-explicit-boolean.patch

@@ -0,0 +1,33 @@
+commit e223d1fe72e820d96f43831412ab267a1ace04d0
+Author: steve ellcey-CA Eng-Software <sellcey@sellcey-thinkpad.caveonetworks.com>
+Date:   Fri Oct 14 12:53:27 2016 -0700
+
+    Fix warnings from latest GCC.
+    
+            * sysdeps/ieee754/dbl-64/e_pow.c (checkint) Make conditions explicitly
+            boolean.
+
+diff --git a/sysdeps/ieee754/dbl-64/e_pow.c b/sysdeps/ieee754/dbl-64/e_pow.c
+index 663fa392c2..bd758b5979 100644
+--- a/sysdeps/ieee754/dbl-64/e_pow.c
++++ b/sysdeps/ieee754/dbl-64/e_pow.c
+@@ -466,15 +466,15 @@ checkint (double x)
+     return (n & 1) ? -1 : 1;	/* odd or even */
+   if (k > 20)
+     {
+-      if (n << (k - 20))
++      if (n << (k - 20) != 0)
+ 	return 0;		/* if not integer */
+-      return (n << (k - 21)) ? -1 : 1;
++      return (n << (k - 21) != 0) ? -1 : 1;
+     }
+   if (n)
+     return 0;			/*if  not integer */
+   if (k == 20)
+     return (m & 1) ? -1 : 1;
+-  if (m << (k + 12))
++  if (m << (k + 12) != 0)
+     return 0;
+-  return (m << (k + 11)) ? -1 : 1;
++  return (m << (k + 11) != 0) ? -1 : 1;
+ }

patches/glibc/linaro-2.20-2014.11/940-nis-bogus-conditional.patch

@@ -0,0 +1,62 @@
+commit f88759ea9bd3c8d8fef28f123ba9767cb0e421a3
+Author: Joseph Myers <joseph@codesourcery.com>
+Date:   Wed Dec 21 23:44:01 2016 +0000
+
+    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
+    snprintf).
+    
+    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
+    declarations.)
+    
+            [BZ #20978]
+            * nis/nss_nisplus/nisplus-alias.c (_nss_nisplus_getaliasbyname_r):
+            Compare name == NULL, not name != NULL.
+
+diff --git a/nis/nss_nisplus/nisplus-alias.c b/nis/nss_nisplus/nisplus-alias.c
+index 7f698b4e6d..cb5acce01d 100644
+--- a/nis/nss_nisplus/nisplus-alias.c
++++ b/nis/nss_nisplus/nisplus-alias.c
+@@ -291,7 +291,7 @@ _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
+ 	return status;
+     }
+ 
+-  if (name != NULL)
++  if (name == NULL)
+     {
+       *errnop = EINVAL;
+       return NSS_STATUS_UNAVAIL;