netdev - UDP packets arriving on wrong sockets

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:   Thu, 2 Aug 2018 05:05:05 -0400
From:   Andrew Cann <shum@...ndrew.org>
To:     netdev@...r.kernel.org
Subject: UDP packets arriving on wrong sockets

Hi, 

I posted this on stackoverflow yesterday but I'm reposting it here since it got
no response. Original post: https://stackoverflow.com/questions/51630337/udp-packets-arriving-on-wrong-sockets-on-linux

I have two UDP sockets bound to the same address and connected to addresses A
and B. I have two more UDP sockets bound to A and B and not connected.

This is what my /proc/net/udp looks like (trimmed for readability):

      sl  local_address rem_address
     3937: 0100007F:DD9C 0300007F:9910
     3937: 0100007F:DD9C 0200007F:907D
    16962: 0200007F:907D 00000000:0000
    19157: 0300007F:9910 00000000:0000

According to connect(2): "If the socket sockfd is of type SOCK_DGRAM, then addr
is the address to which datagrams are sent by default, *and the only address
from which datagrams are received*."

For some reason, my connected sockets are receiving packets that were destined
for each other. eg: The UDP socket connected to A sends a message to A, A then
sends a reply back. The UDP socket connected to B sends a message to B, B then
sends a reply back. But the reply from A arrives at the socket connected to B
and the reply from B arrives at the socket connected to A.

Why on earth would this be happening? Note that it happens randomly - sometimes
the replies arrive at the correct sockets and sometimes they don't. Is there
any way to prevent this or any situation under which connect() is supposed to
not work?

Any help explaining this would be hugely appreciated :)

 - Andrew

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)