diff options
Diffstat (limited to 'patches')
40 files changed, 2223 insertions, 0 deletions
diff --git a/patches/glibc/2.12.1/920-fix-rpc_parse-format.patch b/patches/glibc/2.12.1/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.12.1/940-nis-bogus-conditional.patch b/patches/glibc/2.12.1/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.12.2/920-fix-rpc_parse-format.patch b/patches/glibc/2.12.2/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.12.2/940-nis-bogus-conditional.patch b/patches/glibc/2.12.2/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.13/920-fix-rpc_parse-format.patch b/patches/glibc/2.13/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.13/940-nis-bogus-conditional.patch b/patches/glibc/2.13/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.14.1/920-fix-rpc_parse-format.patch b/patches/glibc/2.14.1/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.14.1/940-nis-bogus-conditional.patch b/patches/glibc/2.14.1/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.14/920-fix-rpc_parse-format.patch b/patches/glibc/2.14/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.14/940-nis-bogus-conditional.patch b/patches/glibc/2.14/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.15/920-fix-rpc_parse-format.patch b/patches/glibc/2.15/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.15/940-nis-bogus-conditional.patch b/patches/glibc/2.15/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.16.0/920-fix-rpc_parse-format.patch b/patches/glibc/2.16.0/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.16.0/940-nis-bogus-conditional.patch b/patches/glibc/2.16.0/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.17/920-fix-rpc_parse-format.patch b/patches/glibc/2.17/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.17/940-nis-bogus-conditional.patch b/patches/glibc/2.17/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.18/920-fix-rpc_parse-format.patch b/patches/glibc/2.18/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.18/940-nis-bogus-conditional.patch b/patches/glibc/2.18/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.19/920-fix-rpc_parse-format.patch b/patches/glibc/2.19/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.19/930-explicit-boolean.patch b/patches/glibc/2.19/930-explicit-boolean.patch new file mode 100644 index 0000000..780fae6 --- /dev/null +++ b/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; + } diff --git a/patches/glibc/2.19/940-nis-bogus-conditional.patch b/patches/glibc/2.19/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.20/920-fix-rpc_parse-format.patch b/patches/glibc/2.20/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.20/930-explicit-boolean.patch b/patches/glibc/2.20/930-explicit-boolean.patch new file mode 100644 index 0000000..780fae6 --- /dev/null +++ b/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; + } diff --git a/patches/glibc/2.20/940-nis-bogus-conditional.patch b/patches/glibc/2.20/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.21/920-fix-rpc_parse-format.patch b/patches/glibc/2.21/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.21/930-explicit-boolean.patch b/patches/glibc/2.21/930-explicit-boolean.patch new file mode 100644 index 0000000..780fae6 --- /dev/null +++ b/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; + } diff --git a/patches/glibc/2.21/940-nis-bogus-conditional.patch b/patches/glibc/2.21/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.21/950-dlclose-assert.patch b/patches/glibc/2.21/950-dlclose-assert.patch new file mode 100644 index 0000000..6e2fcff --- /dev/null +++ b/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) diff --git a/patches/glibc/2.22/920-fix-rpc_parse-format.patch b/patches/glibc/2.22/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.22/930-explicit-boolean.patch b/patches/glibc/2.22/930-explicit-boolean.patch new file mode 100644 index 0000000..780fae6 --- /dev/null +++ b/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; + } diff --git a/patches/glibc/2.22/940-nis-bogus-conditional.patch b/patches/glibc/2.22/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.23/920-fix-rpc_parse-format.patch b/patches/glibc/2.23/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.23/930-explicit-boolean.patch b/patches/glibc/2.23/930-explicit-boolean.patch new file mode 100644 index 0000000..780fae6 --- /dev/null +++ b/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; + } diff --git a/patches/glibc/2.23/940-nis-bogus-conditional.patch b/patches/glibc/2.23/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/2.24/920-fix-rpc_parse-format.patch b/patches/glibc/2.24/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/2.24/930-explicit-boolean.patch b/patches/glibc/2.24/930-explicit-boolean.patch new file mode 100644 index 0000000..780fae6 --- /dev/null +++ b/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; + } diff --git a/patches/glibc/2.24/940-nis-bogus-conditional.patch b/patches/glibc/2.24/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; diff --git a/patches/glibc/linaro-2.20-2014.11/920-fix-rpc_parse-format.patch b/patches/glibc/linaro-2.20-2014.11/920-fix-rpc_parse-format.patch new file mode 100644 index 0000000..37e58da --- /dev/null +++ b/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) + { diff --git a/patches/glibc/linaro-2.20-2014.11/930-explicit-boolean.patch b/patches/glibc/linaro-2.20-2014.11/930-explicit-boolean.patch new file mode 100644 index 0000000..780fae6 --- /dev/null +++ b/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; + } diff --git a/patches/glibc/linaro-2.20-2014.11/940-nis-bogus-conditional.patch b/patches/glibc/linaro-2.20-2014.11/940-nis-bogus-conditional.patch new file mode 100644 index 0000000..09b38cf --- /dev/null +++ b/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; |