[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKHv7phiiS2PZMRXMYnZVqU3soMFx4EbJ33++W8kD0ztJbmp3Q@mail.gmail.com>
Date: Sun, 20 Oct 2013 14:26:08 +0200
From: Paul Schutte <sjpschutte@...il.com>
To: musl@...ts.openwall.com
Subject: Re: inet_pton problem
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 <sjpschutte@...il.com> 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 <dalias@...ifal.cx> 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
>>
>
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
