Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 11 Feb 2014 12:44:31 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] getaddrinfo: fix service lookup without proto hint

On Tue, Feb 11, 2014 at 05:06:13PM +0100, Clément Vasseur wrote:
> Only enable the service protocol check if a protocol has been specified.
> Otherwise, getaddrinfo(NULL, "tftp", NULL, &res) would return the
> EAI_SERVICE error code because the protocol check was performed even
> though no protocol was specified at all.
> ---
>  src/network/getaddrinfo.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/network/getaddrinfo.c b/src/network/getaddrinfo.c
> index 5d45be7..57c53fd 100644
> --- a/src/network/getaddrinfo.c
> +++ b/src/network/getaddrinfo.c
> @@ -88,7 +88,7 @@ int getaddrinfo(const char *restrict host, const char *restrict serv, const stru
>  				if (strncmp(line, serv, servlen) || !isspace(line[servlen]))
>  					continue;
>  				port = strtoul(line+servlen, &end, 10);
> -				if (strncmp(end, proto==IPPROTO_UDP ? "/udp" : "/tcp", 4))
> +				if (proto && strncmp(end, proto==IPPROTO_UDP ? "/udp" : "/tcp", 4))
>  					continue;

Anyone else have comments on this? My concern was that we don't yet
support returning both tcp and udp serices when proto is unspecified,
and so doing something like this could prevent finding the (presumed
important) tcp service if the (usually nonsensical duplicate) udp
service happened to come first in the services file. But if all
real-world services files have the tcp services first, it probably
doesn't matter, and this patch is probably ok.

With the upcoming (post-1.0) resolver overhaul, this will be a
non-issue since we'll be able to return both easily.

Rich

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.