netdev - Re: [PATCH net] net: fix propagation of EPERM from tcp

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]

Message-ID: <CAHo-OoxLYpbXMZFY+b7Wb8Dh1MNQXb2WEPNnV_+d_MOisipy=A@mail.gmail.com>
Date: Tue, 25 Nov 2025 17:08:17 -0800
From: Maciej Żenczykowski <zenczykowski@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Linux Network Development Mailing List <netdev@...r.kernel.org>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Lorenzo Colitti <lorenzo@...gle.com>, Neal Cardwell <ncardwell@...gle.com>, bpf@...r.kernel.org
Subject: Re: [PATCH net] net: fix propagation of EPERM from tcp_connect()

> FWIW this breaks the mptcp_join.sh test, too:

What do you mean by 'too', does it break something else as well, or
just the quoted mptcp_join?

> https://netdev-3.bots.linux.dev/vmksft-mptcp/results/394900/1-mptcp-join-sh/stdout

My still very preliminary investigation is that this is actually
correct (though obviously the tests need to be adjusted).

See tools/testing/selftests/net/mptcp/mptcp_join.sh:89

# generated using "nfbpf_compile '(ip && (ip[54] & 0xf0) == 0x30) ||
#                                (ip6 && (ip6[74] & 0xf0) == 0x30)'"
CBPF_MPTCP_SUBOPTION_ADD_ADDR=...

mptcp_join.sh:365
      if ! ip netns exec $ns2 $tables -A OUTPUT -p tcp \
                      -m tcp --tcp-option 30 \
                      -m bpf --bytecode \
                      "$CBPF_MPTCP_SUBOPTION_ADD_ADDR" \
                      -j DROP

So basically this is using iptables -j DROP which presumably
propagates to EPERM and thus results in a faster local failure...

Although this is probably trying to replicate packet loss rather than
a local error...

So I'm not sure if I should:
(a) fix the asserts with new values (presumably easiest by far),
or
(b) change how it does DROP to make it more like network packet loss
(maybe an extra namespace, so the drop is in a diff netns, during
forwarding??? not even sure if that would help though, or maybe add
drop on other netns INPUT instead of OUTPUT).
or
(c) introduce some iptables -j DROP_CN type return... (seems like that
might be worthwhile anyway)

I'll think about it.