Hello,
We have come across something that may be a bug, unless this behavior
was intentional.
The problem can be simulated by creating a socket, setting
SO_BINDTODEVICE, and binding to a port. Then, in a separate process we
attempt to bind to the same port but without the SO_BINDTODEVICE option.
The expected behavior is to get EINVAL because the port is already
bound by a prior call. However, it succeeds, and the second process
steals the first process' packets.
The likely code in question resides in net/ipv4/udp.c:
for (sk2 = udp_hash[snum & (UDP_HTABLE_SIZE - 1)];
sk2 != NULL;
sk2 = sk2->next) {
if (sk2->num == snum &&
sk2 != sk &&
sk2->bound_dev_if == sk->bound_dev_if &&
(!sk2->rcv_saddr ||
!sk->rcv_saddr ||
sk2->rcv_saddr == sk->rcv_saddr) &&
(!sk2->reuse || !sk->reuse))
goto fail;
}
The condition (sk2->bound_dev_if == sk->bound_dev_if) will fail because
sk2->bound_dev_if will be the ifindex of the interface we bound to, and
sk->bound_dev_if will be 0, since we didn't bind to a specific
interface.
Lars Ellenberg suggests something like:
| (!sk2->bound_dev_if ||
| !sk->bound_dev_if ||
| sk2->bound_dev_if == sk->bound_dev_if) &&
Which on its face appears to clear the bug. I don't see any obvious
downsides to it either, but this is why I'm here.
So, is this intentional or a bug?
Thanks.
--
- kpd
"If at first you don't succeed, redefine success." - Anonymous
pgpvEAE9mqTaV.pgp
Description: PGP signature
|