From patchwork Tue Dec 20 16:57:59 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 18595 Received: (qmail 69214 invoked by alias); 20 Dec 2016 16:58:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 69204 invoked by uid 89); 20 Dec 2016 16:58:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=plenty, Hx-languages-length:2235 X-HELO: relay1.mentorg.com Date: Tue, 20 Dec 2016 16:57:59 +0000 From: Joseph Myers To: Subject: Fix nss_nisplus build with mainline GCC (bug 20978) Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) 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 retun 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 (and maybe if there are issues that means a separate bug or bugs should be filed to track them). (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.) 2016-12-20 Joseph Myers [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 7f698b4..cb5acce 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;