Re: Race condition between UDP bind(2) and connect(2) delivers wrong datagrams

[John Haxby <john.haxby () oracle com>]

On 06/11/17 18:42, Florian Weimer wrote:
> > Even though it can be difficult to exploit this bug, it is a
> > validation bug
> > in the kernels. POSIX 2008 (2016 edition) says[1]:
> >
> >   "For SOCK_DGRAM sockets, the peer address identifies where all datagrams
> >    are sent on subsequent send() functions, and limits the remote sender
> >    for subsequent recv() functions."
>
> Whatever the exact wording used is, the intent of POSIX is to describe
> the BSD sockets API behavior.  If the API does something else, that's a
> POSIX bug.

It does say "subsequent" and says nothing about datagrams that might be
received by the kernel before the connect(2).

The Linux man page also has this to say:

>   Generally, connection-based protocol sockets may successfully connect()
>   only once; connectionless protocol sockets may use  connect()  multiple
>   times to change their association.  Connectionless sockets may dissolve
>   the association by connecting to an address with the  sa_family  member
>   of sockaddr set to AF_UNSPEC (supported on Linux since kernel 2.2).

I know that that's not Posix, but it underlines the interesting question
of what happens to packets that have already been received that have the
"wrong" source address?

You might hope that the kernel will just flush any datagrams that the
application has picked up.  What happens, though, if the program is
working its way through datagrams that it has received or is receiving
from the kernel?   That's a rhetorical question -- it should, of course,
discard packets it is (no longer) interested in.

While there's plenty of scope for programs to get this wrong, I don't
think the kernel is under any obligation to attempt to flush anything
either from a standards point of view or from a real-world
implementation point of view.

jch