netdev - Re: Question regarding expected behavior of two udp sockets with SO

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20101121005036.GB29311@hmsreliant.think-freely.org>
Date:	Sat, 20 Nov 2010 19:50:36 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: Question regarding expected behavior of two udp sockets with
 SO_REUSEADDR set

On Sat, Nov 20, 2010 at 04:44:47PM +0100, Eric Dumazet wrote:
> Le samedi 20 novembre 2010 à 10:04 -0500, Neil Horman a écrit :
> 
> > Agreed.  My thought was to add logic to udp_lib_lport_inuse such that, if
> > sk_reuse is set on both sockets, and the input snum is 0 (indicating autobind)
> > we should not allow binding sk to inet_sk(sk2)->num.  Thoughts?
> 
> I dont know, problem is this could be possible right now if sk2 is bound
> on 127.0.0.2 address. Adding this test would reduce possible space.
> 
Well, yes, that is in fact the exact problem that I origionally described.  Both
sockets are bound to the same port on 127.0.0.1 on the same system.  Since both
sockets have SO_REUSEADDR set, this is allowed, but when either socket sends  a
messaage, the delivery code does a lookup in __udp4_lib_lookup, and the sock
structure that gets returned there is ambiguous. It could be either of the two
bound sockets, and the result will depend on which order they exist in the
hslot->head list (since they will both by definition hash to the same bucket).

Another solution might be to treat daddr of 127 specially, and force a traversal
of the entire hslot->head list, delivering to every matching packet, but we
might need to do that for all locally owned daddrs, so I'm not sure thats a
great solution.  Other thoughts welcome, including just leave it all well enough
alone :)


> Autobind is tricky, it chooses a port while address is part of the
> problem.
> 
Agreed, I'm comming to understand that :)

Neil

--
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