[Top] [All Lists]

Strange UDP binding behavior (SO_BINDTODEVICE)

To: netdev@xxxxxxxxxxx
Subject: Strange UDP binding behavior (SO_BINDTODEVICE)
From: Kevin Dwyer <kevin@xxxxxxxxxxx>
Date: Sun, 5 Oct 2003 13:01:54 -0400
Cc: linux-ha@xxxxxxxxxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx

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

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?


- kpd
"If at first you don't succeed, redefine success." - Anonymous

Attachment: pgpoSZfPgvXeA.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>