The connect() system call for a UDP socket is for setting the destination
address and port. But the current code mistakenly sets the source address
for the socket as well. Remove the source address setting in connect() for
UDP in this patch.
Implications of the bug:
- Packet drop:
On a multi-homed device, an address assigned to any interface may
qualify as a source address when originating a packet. If needed, the
IP_PKTINFO option can be used to explicitly specify the source address.
But with the source address being mistakenly set for the socket in
connect(), a return packet (for the socket) destined to an interface
address different from that source address would be wrongly dropped
due to address mismatch.
This can be reproduced easily. The dropped packets are shown in the
following output by "netstat -s" for UDP:
xxx packets to unknown port received
- Source address selection:
The source address, if unspecified via "bind()" or IP_PKTINFO, should
be determined by routing at the time of packet origination, and not at
the time when the connect() call is made. The difference matters as
routing can change, e.g., by interface down/up events, and using a
source address of an "down" interface is known to be problematic.
There is no backward compatibility issue here as the source address setting
in connect() is not needed anyway.
- No impact on the source address selection when the source address
is explicitly specified by "bind()", or by the "IP_PKTINFO" option.
- In the case that the source address is not explicitly specified,
the selection of the source address would be more accurate and
reliable based on the up-to-date routing table.
Signed-off-by: Enke Chen <[email protected]>
---
net/ipv4/datagram.c | 7 -------
net/ipv6/datagram.c | 15 +--------------
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index f915abff1350..4065808ec6c1 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -64,13 +64,6 @@ int __ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len
err = -EACCES;
goto out;
}
- if (!inet->inet_saddr)
- inet->inet_saddr = fl4->saddr; /* Update source address */
- if (!inet->inet_rcv_saddr) {
- inet->inet_rcv_saddr = fl4->saddr;
- if (sk->sk_prot->rehash)
- sk->sk_prot->rehash(sk);
- }
inet->inet_daddr = fl4->daddr;
inet->inet_dport = usin->sin_port;
sk->sk_state = TCP_ESTABLISHED;
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index ecf440a4f593..80388cd50dc3 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -197,19 +197,6 @@ int __ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr,
goto out;
ipv6_addr_set_v4mapped(inet->inet_daddr, &sk->sk_v6_daddr);
-
- if (ipv6_addr_any(&np->saddr) ||
- ipv6_mapped_addr_any(&np->saddr))
- ipv6_addr_set_v4mapped(inet->inet_saddr, &np->saddr);
-
- if (ipv6_addr_any(&sk->sk_v6_rcv_saddr) ||
- ipv6_mapped_addr_any(&sk->sk_v6_rcv_saddr)) {
- ipv6_addr_set_v4mapped(inet->inet_rcv_saddr,
- &sk->sk_v6_rcv_saddr);
- if (sk->sk_prot->rehash)
- sk->sk_prot->rehash(sk);
- }
-
goto out;
}
@@ -247,7 +234,7 @@ int __ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr,
* destination cache for it.
*/
- err = ip6_datagram_dst_update(sk, true);
+ err = ip6_datagram_dst_update(sk, false);
if (err) {
/* Restore the socket peer info, to keep it consistent with
* the old socket state
--
2.19.1
Hi, David:
Yes, I understand the code has been there for a long time. But the issues are real, and it's really nasty when
You run into them. As I described in the patch log, there is no backward compatibility Issue for fixing it.
---
There is no backward compatibility issue here as the source address setting
in connect() is not needed anyway.
- No impact on the source address selection when the source address
is explicitly specified by "bind()", or by the "IP_PKTINFO" option.
- In the case that the source address is not explicitly specified,
the selection of the source address would be more accurate and
reliable based on the up-to-date routing table.
---
Thanks. -- Enke
-----Original Message-----
From: <[email protected]> on behalf of David Miller <[email protected]>
Date: Friday, September 6, 2019 at 12:14 AM
To: "Enke Chen (enkechen)" <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "xe-linux-external(mailer list)" <[email protected]>
Subject: Re: [PATCH] net: Remove the source address setting in connect() for UDP
From: Enke Chen <[email protected]>
Date: Thu, 5 Sep 2019 19:54:37 -0700
> The connect() system call for a UDP socket is for setting the destination
> address and port. But the current code mistakenly sets the source address
> for the socket as well. Remove the source address setting in connect() for
> UDP in this patch.
Do you have any idea how many decades of precedence this behavior has and
therefore how much you potentially will break userspace?
This boat has sailed a long time ago I'm afraid.
From: Enke Chen <[email protected]>
Date: Thu, 5 Sep 2019 19:54:37 -0700
> The connect() system call for a UDP socket is for setting the destination
> address and port. But the current code mistakenly sets the source address
> for the socket as well. Remove the source address setting in connect() for
> UDP in this patch.
Do you have any idea how many decades of precedence this behavior has and
therefore how much you potentially will break userspace?
This boat has sailed a long time ago I'm afraid.
Hi, David:
Do you still have concerns about backward compatibility of the fix?
I really do not see how existing, working applications would be negatively impacted
by the fix.
Thanks. -- Enke
-----Original Message-----
From: "Enke Chen (enkechen)" <[email protected]>
Date: Friday, September 6, 2019 at 12:23 AM
To: David Miller <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "xe-linux-external(mailer list)" <[email protected]>, "Enke Chen (enkechen)" <[email protected]>
Subject: Re: [PATCH] net: Remove the source address setting in connect() for UDP
Hi, David:
Yes, I understand the code has been there for a long time. But the issues are real, and it's really nasty when
You run into them. As I described in the patch log, there is no backward compatibility Issue for fixing it.
---
There is no backward compatibility issue here as the source address setting
in connect() is not needed anyway.
- No impact on the source address selection when the source address
is explicitly specified by "bind()", or by the "IP_PKTINFO" option.
- In the case that the source address is not explicitly specified,
the selection of the source address would be more accurate and
reliable based on the up-to-date routing table.
---
Thanks. -- Enke
-----Original Message-----
From: <[email protected]> on behalf of David Miller <[email protected]>
Date: Friday, September 6, 2019 at 12:14 AM
To: "Enke Chen (enkechen)" <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "xe-linux-external(mailer list)" <[email protected]>
Subject: Re: [PATCH] net: Remove the source address setting in connect() for UDP
From: Enke Chen <[email protected]>
Date: Thu, 5 Sep 2019 19:54:37 -0700
> The connect() system call for a UDP socket is for setting the destination
> address and port. But the current code mistakenly sets the source address
> for the socket as well. Remove the source address setting in connect() for
> UDP in this patch.
Do you have any idea how many decades of precedence this behavior has and
therefore how much you potentially will break userspace?
This boat has sailed a long time ago I'm afraid.
From: "Enke Chen (enkechen)" <[email protected]>
Date: Tue, 10 Sep 2019 23:55:59 +0000
> Do you still have concerns about backward compatibility of the fix?
I'm not convinced by your arguments and I am also completely swamped at
LPC2019 running the networking track this week.