From: netdev-bot+sashiko@kernel.org
To: willemdebruijn.kernel@gmail.com
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
shuah@kernel.org, linux-kselftest@vger.kernel.org,
willemb@google.com
Subject: Re: [net-next] selftests: net: csum: filter packets by source address and port
Date: Wed, 02 Sep 2026 07:16:27 +0000 [thread overview]
Message-ID: <178833338726.3394541.13779692240559712632@kernel.org> (raw)
In-Reply-To: <20260831210128.1359978-1-willemdebruijn.kernel@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:
Critical: 0 · High: 1 · Medium: 0 · Low: 0
- [High] Incomplete fix: the patch adds source-address/source-port
filtering only to the PF_PACKET verification path…
--
selftests: net: csum: filter packets by source address and port
The csum receiver now checks the source address and source port in
recv_verify_packet_tcp(), recv_verify_packet_udp(), recv_verify_packet_ipv4()
and recv_verify_packet_ipv6(), skipping non-matching packets. It also adds a
20us inter-packet delay in do_tx() and drops a stale comment at the top of
the file.
> diff --git a/tools/testing/selftests/net/lib/csum.c b/tools/testing/selftests/net/lib/csum.c
> index e28884ce3ab39..139465054f85a 100644
> --- a/tools/testing/selftests/net/lib/csum.c
> +++ b/tools/testing/selftests/net/lib/csum.c
[ ... ]
> @@ -647,6 +649,9 @@ static int recv_verify_packet_udp(void *th, int len)
> return recv_verify_packet_udp_encap(udph + 1,
> len - sizeof(*udph));
>
> + if (!cfg_zero_sum && udph->source != htons(cfg_port_src))
> + return -1;
> +
> return recv_verify_csum(th, len, ntohs(udph->source), udph->check);
> }
[Severity: High]
Does this cover the second receive path used by the UDP tests?
For cfg_proto == IPPROTO_UDP the test also opens a real SOCK_DGRAM socket in
recv_prepare_udp() and drains it in recv_udp(). That socket is only bound to
the local address and cfg_port_dst; there is no connect() to the sender and
recv_udp() uses plain recv() without inspecting the peer:
tools/testing/selftests/net/lib/csum.c:recv_prepare_udp() {
fd = socket(cfg_family, SOCK_DGRAM, 0);
...
if (bind(fd, (void *)&cfg_daddr4, sizeof(cfg_daddr4)))
error(1, errno, "bind r");
}
tools/testing/selftests/net/lib/csum.c:recv_udp() {
while (1) {
ret = recv(fd, buf, sizeof(buf), MSG_DONTWAIT);
...
count++;
}
}
do_rx() then turns that count into a hard failure in exactly the -E case this
patch targets:
tools/testing/selftests/net/lib/csum.c:do_rx() {
if (cfg_proto == IPPROTO_UDP)
count_udp += recv_udp(fdr);
...
if (cfg_bad_csum && count_udp)
error(1, 0, "rx: unexpected packets at udp");
}
The test's own crafted bad-checksum datagrams are dropped by the kernel UDP
checksum check, so count_udp is expected to stay zero. An unrelated
background datagram sent to the local address at cfg_port_dst with a valid
checksum is delivered to this socket and counted, and the test aborts. The
in-tree cases ipv4_rx_udp_invalid and ipv6_rx_udp_invalid in
tools/testing/selftests/drivers/net/hw/csum.py run csum with -E and UDP, so
they still appear exposed to background traffic after this change.
Would it make sense to also connect() the receive UDP socket to
cfg_saddr:cfg_port_src, or use recvfrom() and drop datagrams whose peer does
not match, with the same cfg_zero_sum exception used above since the source
port is computed at send time in that mode?
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260831210128.1359978-1-willemdebruijn.kernel%40gmail.com
next prev parent reply other threads:[~2026-09-02 7:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 21:01 [PATCH net-next] selftests: net: csum: filter packets by source address and port Willem de Bruijn
2026-09-02 7:16 ` netdev-bot+sashiko [this message]
2026-09-02 18:24 ` [net-next] " Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178833338726.3394541.13779692240559712632@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox