lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4910BBC0.1060309@hp.com>
Date:	Tue, 04 Nov 2008 16:16:48 -0500
From:	Brian Haley <brian.haley@...com>
To:	Chuck Lever <chuck.lever@...cle.com>
CC:	netdev@...r.kernel.org
Subject: Re: ipv6_addr_type() and mapped IPv4 loopback

Chuck Lever wrote:
> Hi Brian-
> 
> On Nov 3, 2008, at Nov 3, 2008, 9:33 PM, Brian Haley wrote:
>> Chuck Lever wrote:
>>> The __ipv6_addr_type() function does not recognize the mapped IPv4 
>>> loopback address:
>>>   ::ffff:7f00:0001
>>> as type IPV6_ADDR_LOOPBACK.  Is this intentional?
>>
>> I would think that since the IPv6 loopback address is ::1, and 
>> ipv4-mapped is ::ffff:* that this would be IPV6_ADDR_MAPPED.  That's 
>> what RFC 4291 seems to say.
> 
> So the answer to my original question is then "yes, this is 
> intentional," correct?

I didn't design the Linux IPv6 stack, but it looks right to me.

> On a system with an AF_INET6 listener, legacy applications use 127.0.0.1 
> to contact a local listener.  The incoming source address will be 
> ::ffff:7f00:0001, not ::1.  This means IPv6-enabled applications have to 
> perform a separate check for ::ffff:7f00:0001 if they are looking for 
> loopback addresses.

Right, applications have to see if it's really an IPv4 address if 
necessary.  If you're just looking for loopback and it's in the kernel, 
it's only about this much code:

	if (ipv6_addr_type(addr->sin6_addr) == IPV6_ADDR_MAPPED) {
                 __be32 v4addr = addr->sin6_addr.s6_addr32[3];
                 if (ipv4_is_loopback(v4addr)) {
                         /* it's 127.0.0.* */
                 }
	}

There's the IN6_IS_ADDR_V4MAPPED() macro for user-space as well.

> The kernel's lockd must verify that an NLM request comes from the local 
> user space.  It's not a lot of extra logic, but it is a subtlety.

Agreed.

-Brian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ