netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 31 Aug 2021 19:29:15 -0700
From:   David Ahern <dsahern@...il.com>
To:     Paul Menzel <pmenzel@...gen.mpg.de>,
        Saikrishna Arcot <sarcot@...rosoft.com>,
        Mike Manning <mmanning@...tta.att-mail.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: Change in behavior for bound vs unbound sockets

On 8/31/21 3:12 AM, Paul Menzel wrote:
>> 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.
> 
> Commit 6da5b0f027a8 (net: ensure unbound datagram socket to be chosen
> when not in a VRF) was added to Linux 5.0.
> 
>> 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?
> If it breaks user space, the old behavior needs to be restored according
> to Linux’ no regression policy. Let’s hope, in the future, there is
> better testing infrastructure and such issues are noticed earlier.

5.0 was 2-1/2 years ago.

Feel free to add tests to tools/testing/selftests/net/fcnal-test.sh to
cover any missing permutations, including what you believe is the
problem here. Both IPv4 and IPv6 should be added for consistency across
protocols.

nettest.c has a lot of the networking APIs, supports udp, tcp, raw, ...