Strange UDP binding behavior (SO_BINDTODEVICE)

[Kevin Dwyer <kevin@pheared.net>]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]