netdev - Change in behavior for bound vs unbound 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]

Message-ID: <BL0PR2101MB13167E456C5E839426BCDBE6D9CB9@BL0PR2101MB1316.namprd21.prod.outlook.com>
Date:   Mon, 30 Aug 2021 23:47:53 +0000
From:   Saikrishna Arcot <sarcot@...rosoft.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Change in behavior for bound vs unbound sockets

Hi all,

When upgrading from 4.19.152 to 5.10.40, I noticed a change in behavior in how incoming UDP packets are assigned to sockets that are bound to an interface and a socket that is not bound to any interface. This affects the dhcrelay program in isc-dhcp, when it is compiled to use regular UDP sockets and not raw sockets.

For each interface it finds on the system (or is passed in via command-line), dhcrelay opens a UDP socket listening on port 67 and bound to that interface. Then, at the end, it opens a UDP socket also listening on port 67, but not bound to any interface (this socket is used for sending, mainly). It expects that for packets that arrived on an interface for which a bound socket is opened, it will arrive on that bound socket. This was true for 4.19.152, but on 5.10.40, packets arrive on the unbound socket only, and never on the bound socket. dhcrelay discards any packets that it sees on the unbound socket. Because of this, this application breaks.

I made a test application that creates two UDP sockets, binds one of them to the loopback interface, and has them both listen on 0.0.0.0 with some random port. Then, it waits for a message on those two sockets, and prints out which socket it received a message on. With another application (such as nc) sending some UDP message, I can see that on 4.19.152, the test application gets the message on the bound socket consistently, whereas on 5.10.40, it gets the message on the unbound socket consistently. I have a dev machine running 5.4.0, and it gets the message on the unbound socket consistently as well.

I traced it to one commit (6da5b0f027a8 "net: ensure unbound datagram socket to be chosen when not in a VRF") that makes sure that when not in a VRF, the unbound socket is chosen over the bound socket, if both are available. If I revert this commit and two other commits that made changes on top of this, I can see that packets get sent to the bound socket instead. There's similar commits made for TCP and raw sockets as well, as part of that patch series.

Is the intention of those commits also meant to affect sockets that are bound to just regular interfaces (and not only VRFs)? If so, since this change breaks a userspace application, is it possible to add a config that reverts to the old behavior, where bound sockets are preferred over unbound sockets?

--
Saikrishna Arcot