netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 19 Nov 2010 19:48:47 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	netdev@...r.kernel.org
Cc:	davem@...emloft.net, eric.dumazet@...il.com, nhorman@...driver.com
Subject: Question regarding expected behavior of two udp sockets with
 SO_REUSEADDR set

Hey all-

	Got a question regarding expected/desired behavior of $SUBJECT

I have a report of a problem with a program that opens two sockets:

The first socket is UDP and binds to 127.0.0.1 on a randomly selected port

The second socket is UDP and calls connect, sending to the first socket

Both sockets are part of the same process and have SO_REUSEADDR set

After the connect the second socket sends a message to the first socket.  The
first socket waits for the message by calling select().

Its observed that occasionally the first socket fails to receive the message,
which is odd, given that the system is unloaded, and this is the only message
being sent.  A little investigation shows that when this happens, the client and
the server wind up bound to the same port.

This happens because the second socket calls inet_autobind during the connect
call, and since both it and the server have SO_REUSEADDR set, it is possible
that the autobind will select the same port that the first socket is bound to.
When this happens the sendmsg path can get confused.  Specifically, when the skb
is delivered to the destination socket, the hash lookup might find the wrong
entry and enqueue the skb to the second socket instead of the first.

Questions:

1) Is that expected?

2) If not, what do you think the best way to fix it is?

	a) Deny autobinds to the same port when SO_REUSEADDR is set, but allow
explicity binds to the same port?

	b) Deny both autobinds and explicit binds to the same port/addr,
effectively disablind SO_REUSEADDR with UDP, kind of like with listening TCP
sockets

	c) Add magic to udp_rcv to detect skbs originating from local sockets,
and _dont_ deliver to the socket it originated from

I'm inclined to say, no this is not expected behavior, and that we should fix it
with option A, but I'm interested in getting other opinions before I go down any
particular path.

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