From: sashiko-bot@kernel.org
To: "Gang Yan" <gang.yan@linux.dev>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-net] selftests: mptcp: fix an UAF in mptcp_connect.c
Date: Fri, 14 Aug 2026 05:14:40 +0000 [thread overview]
Message-ID: <20260814051440.DD4F71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814050625.80231-1-gang.yan@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] sock_reconnect() unconditionally connects to the first resolved address instead of iterating, introducing a logic regression for multi-IP hosts.
--
--- Patch [1]: [PATCH mptcp-net] selftests: mptcp: fix an UAF in mptcp_connect.c ---
commit 0dae1d93a2aa0c4ea91bddbe5e055fd748d90080
Author: Gang Yan <yangang@kylinos.cn>
selftests: mptcp: fix an UAF in mptcp_connect.c
This patch removes the peer out-parameter from sock_connect_mptcp() to prevent a
use-after-free issue when the original address memory is freed. It introduces a
sock_reconnect() helper to resolve the address and connect independently
during reconnection attempts.
> diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.c b/tools/testing/selftests/net/mptcp/mptcp_connect.c
> index cbe573c4ab3ad..05ab9887485c0 100644
> --- a/tools/testing/selftests/net/mptcp/mptcp_connect.c
> +++ b/tools/testing/selftests/net/mptcp/mptcp_connect.c
[ ... ]
> @@ -427,6 +424,22 @@ static int sock_connect_mptcp(const char * const remoteaddr,
> return sock;
> }
>
> +static int sock_reconnect(const char *host, const char *port, int fd)
> +{
> + struct addrinfo hints = {
> + .ai_socktype = SOCK_STREAM,
> + .ai_family = pf,
> + };
> + struct addrinfo *addr;
> + int ret;
> +
> + xgetaddrinfo(host, port, &hints, &addr);
> + ret = connect(fd, addr->ai_addr, addr->ai_addrlen);
[Severity: Medium]
Will this unconditionally connect to the first address returned by
xgetaddrinfo() without iterating or attempting fallbacks?
The original connection logic in sock_connect_mptcp() implicitly saved the
successful connection address by keeping a pointer to the successful node
in the addrinfo list. By resolving the host again and blindly connecting to
the first returned address without looping, could this cause the selftest
to spuriously fail if the host resolves to multiple IPs (like dual-stack
IPv4/IPv6 on localhost) and the first address is not the one previously used?
> + freeaddrinfo(addr);
> +
> + return ret;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814050625.80231-1-gang.yan@linux.dev?part=1
next prev parent reply other threads:[~2026-08-14 5:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 5:06 [PATCH mptcp-net] selftests: mptcp: fix an UAF in mptcp_connect.c Gang Yan
2026-08-14 5:14 ` sashiko-bot [this message]
2026-08-14 6:18 ` MPTCP CI
2026-08-14 6:42 ` gang.yan
2026-08-14 8:54 ` Matthieu Baerts
2026-08-14 9:20 ` gang.yan
2026-08-14 9:35 ` Matthieu Baerts
2026-08-14 10:50 ` Paolo Abeni
2026-08-14 14:20 ` gang.yan
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=20260814051440.DD4F71F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=gang.yan@linux.dev \
--cc=mptcp@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox