From: sashiko-bot@kernel.org
To: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Cc: mptcp@lists.linux.dev, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 02/11] mptcp: remove unused data_ack from struct mptcp_ext
Date: Thu, 13 Aug 2026 14:56:33 +0000 [thread overview]
Message-ID: <20260813145634.20BB31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812-net-next-mptcp-misc-feat-7-3-v1-2-1905a818f6cb@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] When transmitting an MPTCP DATA_FIN DSS option without a data payload (e.g., on a pure ACK), the stack-allocated `opts.mptcp.ext_copy.csum` is left uninitialized. If MPTCP checksums are enabled, this uninitialized memory is written to the TCP header, leaking 2 bytes of kernel stack memory over the network.
--
--- Patch [2]: [PATCH net-next 02/11] mptcp: remove unused data_ack from struct mptcp_ext ---
commit 5596db7582bd748ad6320aef70bbdd448c28de36
Author: Geliang Tang <geliang@kernel.org>
mptcp: remove unused data_ack from struct mptcp_ext
The data_ack and data_ack32 fields in struct mptcp_ext are no longer used
anywhere. Remove them from the structure and update mptcp_dump_mpext()
trace helper accordingly. Drop the data_ack field from the trace entry
and the corresponding output in TP_printk().
> diff --git a/include/net/mptcp.h b/include/net/mptcp.h
> index 71b9fc5a57963..485d55b66ea67 100644
> --- a/include/net/mptcp.h
> +++ b/include/net/mptcp.h
> @@ -19,10 +19,6 @@ struct seq_file;
>
> /* MPTCP sk_buff extension data */
> struct mptcp_ext {
> - union {
> - u64 data_ack;
> - u32 data_ack32;
> - };
> u64 data_seq;
> u32 subflow_seq;
> u16 data_len;
[Severity: Medium]
This is a pre-existing issue, but does this structure leave the csum field
uninitialized on the stack under certain conditions?
When transmitting an MPTCP DATA_FIN DSS option without a data payload (e.g.,
on a pure ACK), the stack-allocated opts structure in
net/ipv4/tcp_output.c:__tcp_transmit_skb() is not fully zeroed:
struct tcp_out_options opts;
If mpext is NULL, net/mptcp/options.c:mptcp_established_options_dss() only
clears the bitfield flags:
/* Zero `use_ack` and `use_map` flags with one shot. */
memset(&opts->ext_copy.flags, 0, sizeof(opts->ext_copy.flags));
This leaves opts->ext_copy.csum uninitialized. The code then passes this to
net/mptcp/options.c:mptcp_write_data_fin(), which populates fields like
data_fin and data_seq but fails to initialize the csum field.
Finally, in net/mptcp/options.c:mptcp_write_options(), it reads the
uninitialized csum when writing the TCP header:
put_len_csum(mpext->data_len,
(mpext->data_len ? mptcp_make_csum(mpext) : 0),
ptr);
Could this uninitialized struct memory result in leaking 2 bytes of kernel
stack memory over the network when MPTCP checksums are enabled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260812-net-next-mptcp-misc-feat-7-3-v1-0-1905a818f6cb@kernel.org?part=2
next prev parent reply other threads:[~2026-08-13 14:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 14:55 [PATCH net-next 00/11] mptcp: misc. features for v7.3 Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 01/11] mptcp: pm: add WARN_ON_ONCE guards on extra_subflows underflow Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 02/11] mptcp: remove unused data_ack from struct mptcp_ext Matthieu Baerts (NGI0)
2026-08-13 14:56 ` sashiko-bot [this message]
2026-08-12 14:55 ` [PATCH net-next 03/11] mptcp: pm: userspace: make remove_addr_entry static Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 04/11] mptcp: honour configured min/max RTO in retransmit paths Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 05/11] mptcp: add per-event MIB counters for MPTCP_RST_EMPTCP resets Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 06/11] selftests: mptcp: check per-event MPTCP_RST_EMPTCP counters Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 07/11] selftests: mptcp: connect: test name in pcap file Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 08/11] selftests: mptcp: simult_flow: " Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 09/11] selftests: mptcp: pcap: drop most of the payload Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 10/11] selftests: mptcp: fix const qualifier warnings in strchr usage Matthieu Baerts (NGI0)
2026-08-12 14:55 ` [PATCH net-next 11/11] selftests: mptcp: diag: fix stack buffer overflow in get_subflow_info() Matthieu Baerts (NGI0)
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=20260813145634.20BB31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=matttbe@kernel.org \
--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 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.