Message ID | alpine.DEB.2.00.1806181539250.20622@tp.orcam.me.uk |
---|---|
State | Superseded |
Headers |
Received: (qmail 33895 invoked by alias); 18 Jun 2018 15:10:45 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 33883 invoked by uid 89); 18 Jun 2018 15:10:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, SPF_PASS autolearn=ham version=3.3.2 spammy=gid, H*r:0700 X-HELO: 9pmail.ess.barracuda.com Date: Mon, 18 Jun 2018 16:10:27 +0100 From: "Maciej W. Rozycki" <macro@mips.com> To: <libc-alpha@sourceware.org> Subject: [PATCH] nisplus: Correct pwent parsing issue and resulting compilation error Message-ID: <alpine.DEB.2.00.1806181539250.20622@tp.orcam.me.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: mipsdag02.mipstec.com (10.20.40.47) To mipsdag02.mipstec.com (10.20.40.47) X-BESS-ID: 1529334639-531716-5140-146859-1 X-BESS-VER: 2018.7-r1806151722 X-BESS-Apparent-Source-IP: 12.201.5.32 X-BESS-Envelope-From: Maciej.Rozycki@mips.com X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-Orig-Rcpt: libc-alpha@sourceware.org X-BESS-BRTS-Status: 1 |
Commit Message
Maciej W. Rozycki
June 18, 2018, 3:10 p.m. UTC
Copy and null-terminate NIS+ password file UID and GID entries whose length is non-zero rather than zero, fixing a bug and a compilation issue causing an error with GCC 8: nss_nisplus/nisplus-parser.c: In function '_nss_nisplus_parse_pwent': nss_nisplus/nisplus-parser.c:90:7: error: 'strncpy' destination unchanged after copying no bytes [-Werror=stringop-truncation] strncpy (first_unused, numstr, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nss_nisplus/nisplus-parser.c:106:7: error: 'strncpy' destination unchanged after copying no bytes [-Werror=stringop-truncation] strncpy (first_unused, numstr, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ introduced with commit ac05397075f6: commit ac05397075f621cfdbe1db527c96167a58b6d18e Author: Ulrich Drepper <drepper@redhat.com> Date: Sun Apr 30 07:01:26 2006 +0000 * nis/nss_nisplus/nisplus-parser.c: Minor optimizations and cleanups. Avoid copying data if it can be used in the old place. (no mailing list reference available). Obviously regardless of the recently added compiler diagnostics causing a build error this code has been long non-functional, so I guess NIS+ servers have been supplying strings that have already been null-terminated. Which in turn made it unnecessary to make a null-terminated copy, masking this bug. * nis/nss_nisplus/nisplus-parser.c (_nss_nisplus_parse_pwent): Copy and null-terminate entries whose length is non-zero rather than zero. --- Hi, No issues seen in `mips-linux-gnu' o32 testing. OK to apply? Also this may have to be backported and security implications evaluated. Maciej --- nis/nss_nisplus/nisplus-parser.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) glibc-nisplus-parse-pwent-len.diff
Comments
On Mon, 18 Jun 2018, Maciej W. Rozycki wrote: > Copy and null-terminate NIS+ password file UID and GID entries whose > length is non-zero rather than zero, fixing a bug and a compilation > issue causing an error with GCC 8: Note: (a) the warnings are bug 23266, (b) we now have alternative candidate patches, as there's <https://sourceware.org/ml/libc-alpha/2018-04/msg00209.html> as well, (c) as I said in <https://sourceware.org/ml/libc-alpha/2018-03/msg00532.html> it would be a very good idea to add a --enable-obsolete-rpc --enable-obsolete-nsl configuration to build-many-glibcs.py so issues building such a configuration with new GCC get detected and fixed quicker.
On Jun 18 2018, "Maciej W. Rozycki" <macro@mips.com> wrote: > Index: glibc/nis/nss_nisplus/nisplus-parser.c > =================================================================== > --- glibc.orig/nis/nss_nisplus/nisplus-parser.c 2018-02-14 14:57:00.000000000 +0000 > +++ glibc/nis/nss_nisplus/nisplus-parser.c 2018-06-16 21:47:29.071633078 +0100 > @@ -82,7 +82,7 @@ _nss_nisplus_parse_pwent (nis_result *re > > char *numstr = NISOBJVAL (2, obj); > len = NISOBJLEN (2, obj); > - if (len == 0 && numstr[len - 1] != '\0') > + if (len != 0 && numstr[len - 1] != '\0') > { > if (len >= room_left) > goto no_more_room; > @@ -98,7 +98,7 @@ _nss_nisplus_parse_pwent (nis_result *re > > numstr = NISOBJVAL (3, obj); > len = NISOBJLEN (3, obj); > - if (len == 0 && numstr[len - 1] != '\0') > + if (len != 0 && numstr[len - 1] != '\0') > { > if (len >= room_left) > goto no_more_room; > I don't think this is correct. If len == 0 then numstr[0] is undefined. Andreas.
On Mon, 18 Jun 2018, Joseph Myers wrote: > > Copy and null-terminate NIS+ password file UID and GID entries whose > > length is non-zero rather than zero, fixing a bug and a compilation > > issue causing an error with GCC 8: > > Note: (a) the warnings are bug 23266, (b) we now have alternative > candidate patches, as there's > <https://sourceware.org/ml/libc-alpha/2018-04/msg00209.html> as well, (c) Umm, I didn't notice `_nss_nisplus_parse_grent' suffers from the same problem and neither GCC bothered here for some reason. > as I said in <https://sourceware.org/ml/libc-alpha/2018-03/msg00532.html> > it would be a very good idea to add a --enable-obsolete-rpc > --enable-obsolete-nsl configuration to build-many-glibcs.py so issues > building such a configuration with new GCC get detected and fixed quicker. Hmm, but why it's been 2+ months and such an obvious fix hasn't been reviewed yet? Insufficient pinging? Maciej
On Mon, 18 Jun 2018, Maciej W. Rozycki wrote: > > as I said in <https://sourceware.org/ml/libc-alpha/2018-03/msg00532.html> > > it would be a very good idea to add a --enable-obsolete-rpc > > --enable-obsolete-nsl configuration to build-many-glibcs.py so issues > > building such a configuration with new GCC get detected and fixed quicker. > > Hmm, but why it's been 2+ months and such an obvious fix hasn't been > reviewed yet? Insufficient pinging? Only pinged once as far as I can see. Quite likely most developers aren't using those configure options and so aren't affected by the issue.
Index: glibc/nis/nss_nisplus/nisplus-parser.c =================================================================== --- glibc.orig/nis/nss_nisplus/nisplus-parser.c 2018-02-14 14:57:00.000000000 +0000 +++ glibc/nis/nss_nisplus/nisplus-parser.c 2018-06-16 21:47:29.071633078 +0100 @@ -82,7 +82,7 @@ _nss_nisplus_parse_pwent (nis_result *re char *numstr = NISOBJVAL (2, obj); len = NISOBJLEN (2, obj); - if (len == 0 && numstr[len - 1] != '\0') + if (len != 0 && numstr[len - 1] != '\0') { if (len >= room_left) goto no_more_room; @@ -98,7 +98,7 @@ _nss_nisplus_parse_pwent (nis_result *re numstr = NISOBJVAL (3, obj); len = NISOBJLEN (3, obj); - if (len == 0 && numstr[len - 1] != '\0') + if (len != 0 && numstr[len - 1] != '\0') { if (len >= room_left) goto no_more_room;