From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4131 Path: news.gmane.org!not-for-mail From: Paul Schutte Newsgroups: gmane.linux.lib.musl.general Subject: Re: inet_pton problem Date: Sun, 20 Oct 2013 14:26:08 +0200 Message-ID: References: <20131020022218.GG20515@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae9cc9640a64c9404e92b4595 X-Trace: ger.gmane.org 1382271978 7909 80.91.229.3 (20 Oct 2013 12:26:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2013 12:26:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4135-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 20 14:26:22 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VXs5N-0002gA-8c for gllmg-musl@plane.gmane.org; Sun, 20 Oct 2013 14:26:21 +0200 Original-Received: (qmail 32293 invoked by uid 550); 20 Oct 2013 12:26:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32285 invoked from network); 20 Oct 2013 12:26:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=h6v64EiXGZf0qebRaEuOm8d2nX0gELQ2v7BzEzLxvdA=; b=pInaXS8VBcqsph6x4dBMfOe9xcvh+kP1zTMkVXuf/c2b0p83TKhMb2V3Ev5z4A8wLQ tB1/qbtjecFfHIk5wpLdQfNBSt8dtydtsQS9W2kprohsKRjXmf0pWwxeKL6i6CPP9Dx8 6A7W9T9pisFz+c2YII+K5KuX3kVAtTSFCk5girQPovVZrdyRjukBzXvNGF/48toM0hPH T70CxUfJylMep0N/rGvRc26yNHTbrqV+k6XMOqYvAyeBfKpj12aDZ08vmI0IIsX1PPSX QXU9GOwCrB765h/Vno6hWad8xvTShm5No0lw6leV4+2NM8rGLmHzpnKsToW6DMa1UiLa 5CQQ== X-Received: by 10.180.91.101 with SMTP id cd5mr6008303wib.50.1382271968232; Sun, 20 Oct 2013 05:26:08 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:4131 Archived-At: --14dae9cc9640a64c9404e92b4595 Content-Type: text/plain; charset=ISO-8859-1 Hi Rich, Unfortunately this is not the complete fix. Haproxy still complains about invalid networks. The following seems to fix the problem without adding too much bloat: --- a/musl/src/network/inet_pton.c +++ b/musl/src/network/inet_pton.c @@ -14,11 +14,11 @@ return -1; } -int inet_pton(int af, const char *restrict s, void *restrict a0) +int inet_pton(int af, const char *restrict s0, void *restrict a0) { uint16_t ip[8]; unsigned char *a = a0; - const char *z; + const char *z,*s = s0; unsigned long x; int i, j, v, d, brk=-1, need_v4=0; @@ -73,6 +73,10 @@ *a++ = ip[j]>>8; *a++ = ip[j]; } + + /* There must have been valid IPv6 preceding IPv4 dotted-quad */ + if (s==s0) return 0; + if (need_v4 && inet_pton(AF_INET, (void *)s, a-4) <= 0) return 0; return 1; } Regards Paul On Sun, Oct 20, 2013 at 11:50 AM, Paul Schutte wrote: > Hi Rich, > > I agree with you, especially about the bloat part. > > They (haproxy) actually use this function to determine whether the address > they have is a valid IPv6 address. > They pass in either a valid IPv4 or IPv6 address and then rely on this > function to determine which they have (assuming a return value of 0). > > After reading the spec more carefully I realise that -1 should be returned > only when the address family is not AF_INET or AF_INET6. > > By changing the return value in the IPv6 code to 0 instead of -1, we could > get the correct behaviour without any extra code. > > Here is a patch to try and save you a bit of work: > > --- a/musl/src/network/inet_pton.c > +++ b/musl/src/network/inet_pton.c > @@ -46,24 +46,24 @@ > if (!s[1]) break; > continue; > } > - if (hexval(s[0])<0) return -1; > + if (hexval(s[0])<0) return 0; > while (s[0]=='0' && s[1]=='0') s++; > for (v=j=0; j<5 && (d=hexval(s[j]))>=0; j++) > v=16*v+d; > - if (v > 65535) return -1; > + if (v > 65535) return 0; > ip[i] = v; > if (!s[j]) { > - if (brk<0 && i!=7) return -1; > + if (brk<0 && i!=7) return 0; > break; > } > if (i<7) { > if (s[j]==':') continue; > - if (s[j]!='.') return -1; > + if (s[j]!='.') return 0; > need_v4=1; > i++; > break; > } > - return -1; > + return 0; > } > if (brk>=0) { > memmove(ip+brk+7-i, ip+brk, 2*(i+1-brk)); > @@ -73,6 +73,6 @@ > *a++ = ip[j]>>8; > *a++ = ip[j]; > } > - if (need_v4 &&inet_pton(AF_INET, (void *)s, a-4) <= 0) return -1; > + if (need_v4 &&inet_pton(AF_INET, (void *)s, a-4) <= 0) return 0; > return 1; > } > > Regards > Paul > > > > On Sun, Oct 20, 2013 at 4:22 AM, Rich Felker wrote: > >> On Sat, Oct 19, 2013 at 10:57:00PM +0200, Paul Schutte wrote: >> > Hi, >> > >> > I came across this and believe it is a bug. >> > >> > I have found that when you set str to an IPv4 addr of the from >> > "xxx.xxx.xxx.xxx' while the address family is AF_INET6, then instead of >> > returning a 0 to indicate an invalid IPv6 string, it is converted to >> > gibberish. >> >> From what I can tell, it's not converted to gibberish; instead, it's >> wrongly returning an error (-1) instead of a result indicating an >> invalid input string (0). One could argue that it's a programming >> error not to check this, but inet_pton should not have any reason to >> return -1 if the first argument (af) is valid, so one could also argue >> that such checks would be extraneous bloat. >> >> > inet_pton(AF_INET6, "192.168.1.1', &sa) should return 0 if I understand >> the >> > specification correctly. >> >> Agreed. >> >> Rich >> > > --14dae9cc9640a64c9404e92b4595 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Rich,

Unfortunate= ly this is not the complete fix.

Haproxy still complains about= invalid networks.

The following seems to fix the problem with= out adding too much bloat:

--- a/musl/src/network/inet_pton.c
+++ b/musl/src/network/inet_pton.= c
@@ -14,11 +14,11 @@
=A0=A0=A0=A0=A0=A0=A0 return -1;
=A0}
=A0=
-int inet_pton(int af, const char *restrict s, void *restrict a0)
+i= nt inet_pton(int af, const char *restrict s0, void *restrict a0)
=A0{
=A0=A0=A0=A0=A0=A0=A0 uint16_t ip[8];
=A0=A0=A0=A0=A0=A0=A0 unsi= gned char *a =3D a0;
-=A0=A0=A0=A0=A0=A0 const char *z;
+=A0=A0=A0=A0= =A0=A0 const char *z,*s =3D s0;
=A0=A0=A0=A0=A0=A0=A0 unsigned long x;=A0=A0=A0=A0=A0=A0=A0 int i, j, v, d, brk=3D-1, need_v4=3D0;
=A0
@@= -73,6 +73,10 @@
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *a++ =3D ip[j]>>8;
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 *a++ =3D ip[j];
=A0=A0=A0= =A0=A0=A0=A0 }
+
+=A0=A0=A0=A0=A0=A0 /* There must have been valid IP= v6 preceding IPv4 dotted-quad */
+=A0=A0=A0=A0=A0=A0 if (s=3D=3Ds0) retu= rn 0;
+
=A0=A0=A0=A0=A0=A0=A0 if (need_v4 && inet_pton(AF_INE= T, (void *)s, a-4) <=3D 0) return 0;
=A0=A0=A0=A0=A0=A0=A0 return 1;
=A0}



Regards
Paul
=A0


On Sun, Oct 20, 2013 at 11:50 A= M, Paul Schutte <sjpschutte@gmail.com> wrote:
Hi Rich= ,

I agree with you, especially about the bloat part.
=

They (haproxy) actually use this function to determine wheth= er the address they have is a valid IPv6 address.
They pass in either a valid IPv4 or IPv6 address and then rely on thi= s function to determine which they have (assuming a return value of 0).
=
After reading the spec more carefully I realise that -1 shou= ld be returned only when the address family is not AF_INET or AF_INET6.

By changing the return value in the IPv6 code to 0 instead o= f -1, we could get the correct behaviour without any extra code.
=

Here is a patch to try and save you a bit of work:

--- a/musl/src/network/inet_pton.c
+++ b/musl/src/network/inet_pton.= c
@@ -46,24 +46,24 @@
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 if (!s[1]) break;
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 continue;
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 }
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 if (hexval(s[0])<0) return -1;
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (hexval(s[0])<0) return 0= ;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 while (s[0]=3D=3D'0&= #39; && s[1]=3D=3D'0') s++;
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 for (v=3Dj=3D0; j<5 && (d=3Dhexval(s[j]))>= =3D0; j++)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 v=3D16*v+d;
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (v > 65535) return -1;+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (v > 65535) return 0;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ip[i] =3D v;
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (!s[j]) {
-=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (brk<0 && i!=3D7) = return -1;
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (brk= <0 && i!=3D7) return 0;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 break;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (i<= ;7) {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 if (s[j]=3D=3D':') continue;
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (s[j]!=3D'.') return -1; +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (s[j= ]!=3D'.') return 0;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 need_v4=3D1;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i++;
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 break;
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 }
-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 r= eturn -1;
+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0;
=A0=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0=A0=A0 if (brk>=3D0) {
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 memmove(ip+brk+7-i, ip+brk, 2*(i= +1-brk));
@@ -73,6 +73,6 @@
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 *a++ =3D ip[j]>>8;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 *a++ =3D ip[j];
=A0=A0=A0=A0=A0=A0=A0 }
-=A0=A0=A0=A0=A0=A0 if= (need_v4 &&inet_pton(AF_INET, (void *)s, a-4) <=3D 0) return -1= ;
+=A0=A0=A0=A0=A0=A0 if (need_v4 &&inet_pton(AF_INET, (void *)s, a-4= ) <=3D 0) return 0;
=A0=A0=A0=A0=A0=A0=A0 return 1;
=A0}

Regards
Paul



On Sun, Oct 20, 2013 at 4:22 AM, Rich Felker= <dalias@aerifal.cx> wrote:

Rich


--14dae9cc9640a64c9404e92b4595--