From: sashiko-bot@kernel.org
To: "Mahe Tardy" <mahe.tardy@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 3/4] selftests/bpf: add bpf_icmp_send kfunc IPv6 tests
Date: Fri, 15 May 2026 20:44:44 +0000 [thread overview]
Message-ID: <20260515204444.D8204C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260515194746.50920-4-mahe.tardy@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Buffer truncation and type confusion when calling getsockname() for IPv6 sockets.
--
commit 3f16e831f177058fc11380fe48e08f94594b83bf
Author: Mahe Tardy <mahe.tardy@gmail.com>
selftests/bpf: add bpf_icmp_send kfunc IPv6 tests
This commit extends the existing bpf_icmp_send kfunc tests with IPv6
support. It updates the test suite to handle IPv6 connections and
ICMPv6 error queues.
> diff --git a/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c b/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c
> index b98c0312adadc..d9badfc6e620c 100644
> --- a/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c
> +++ b/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c
[ ... ]
> @@ -78,14 +92,13 @@ static void read_icmp_errqueue(int sockfd, int expected_code)
> }
>
> static void trigger_prog_read_icmp_errqueue(struct icmp_send *skel,
> - int code)
> + int code, int af, const char *ip)
> {
> int srv_fd = -1, client_fd = -1;
> struct sockaddr_in addr;
> socklen_t len = sizeof(addr);
>
> - srv_fd = start_server(AF_INET, SOCK_STREAM, "127.0.0.1", 0,
> - TIMEOUT_MS);
> + srv_fd = start_server(af, SOCK_STREAM, ip, 0, TIMEOUT_MS);
> if (!ASSERT_GE(srv_fd, 0, "start_server"))
> return;
>
> @@ -94,6 +107,8 @@ static void trigger_prog_read_icmp_errqueue(struct icmp_send *skel,
> return;
> }
> skel->bss->server_port = ntohs(addr.sin_port);
When af is AF_INET6, start_server() creates an IPv6 socket, but addr
is hardcoded as struct sockaddr_in which is 16 bytes.
Does this cause getsockname() to silently truncate the 28-byte
sockaddr_in6 structure because len is initialized to sizeof(addr)?
While reading addr.sin_port happens to work because sin_port and sin6_port
share the same offset, would it be better to use struct sockaddr_storage
here (like in connect_to_fd_nonblock() earlier in the file) and extract
the port conditionally based on the address family to avoid type confusion?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260515194746.50920-1-mahe.tardy@gmail.com?part=3
next prev parent reply other threads:[~2026-05-15 20:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 19:47 [PATCH bpf-next v5 0/4] bpf: add icmp_send kfunc Mahe Tardy
2026-05-15 19:47 ` [PATCH bpf-next v5 1/4] bpf: add bpf_icmp_send kfunc Mahe Tardy
2026-05-15 20:23 ` sashiko-bot
2026-05-15 19:47 ` [PATCH bpf-next v5 2/4] selftests/bpf: add bpf_icmp_send kfunc tests Mahe Tardy
2026-05-15 20:36 ` sashiko-bot
2026-05-15 19:47 ` [PATCH bpf-next v5 3/4] selftests/bpf: add bpf_icmp_send kfunc IPv6 tests Mahe Tardy
2026-05-15 20:44 ` sashiko-bot [this message]
2026-05-15 19:47 ` [PATCH bpf-next v5 4/4] selftests/bpf: add bpf_icmp_send recursion test Mahe Tardy
2026-05-15 21:00 ` sashiko-bot
2026-05-16 9:54 ` kernel test robot
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=20260515204444.D8204C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=mahe.tardy@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.