syzbot reported a KMSAN uninit-value in mptcp_write_data_fin() reached
via tcp_send_ack() from the subflow shutdown path:
BUG: KMSAN: uninit-value in mptcp_write_data_fin net/mptcp/options.c:542
mptcp_established_options_dss net/mptcp/options.c:590
mptcp_established_options net/mptcp/options.c:874
tcp_established_options net/ipv4/tcp_output.c:1192
__tcp_transmit_skb net/ipv4/tcp_output.c:1575
__tcp_send_ack net/ipv4/tcp_output.c:4499
tcp_send_ack net/ipv4/tcp_output.c:4505
mptcp_subflow_shutdown net/mptcp/protocol.c:3137
mptcp_check_send_data_fin net/mptcp/protocol.c:3218
__mptcp_wr_shutdown net/mptcp/protocol.c:3234
__mptcp_close net/mptcp/protocol.c:3313
Local variable opts created at:
__tcp_transmit_skb net/ipv4/tcp_output.c:1536
__tcp_transmit_skb() partially clears its on-stack tcp_out_options via
"memset(&opts.cleared, ...)" which does not cover opts.mptcp, so MPTCP
is responsible for initializing opts->ext_copy before use.
mptcp_established_options_dss() only writes opts->ext_copy when an
MPTCP extension is attached to the skb ("opts->ext_copy = *mpext").
When tcp_send_ack() builds a fresh pure-ACK skb during subflow
shutdown, the skb has no extension and that assignment is skipped, but
the function still calls mptcp_write_data_fin(&opts->ext_copy) because
snd_data_fin_enable is set. mptcp_write_data_fin() then reads
ext->use_map to choose between writing a synthetic DATA_FIN mapping or
extending an existing one, and that read hits uninitialized stack
memory.
Zero opts->ext_copy at the top of mptcp_established_options_dss() so
mptcp_write_data_fin() takes its synthetic-mapping branch on clean
memory.
Fixes: 9c29e3615274 ("mptcp: fix DSS map generation on fin retransmission")
Reported-by: syzbot+ff020673c5e3d94d9478@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ff020673c5e3d94d9478
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
net/mptcp/options.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 8a1c5698983c..3fb914196987 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -572,6 +572,7 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
bool ret = false;
u64 ack_seq;
+ memset(&opts->ext_copy, 0, sizeof(opts->ext_copy));
opts->csum_reqd = READ_ONCE(msk->csum_enabled);
mpext = skb ? mptcp_get_ext(skb) : NULL;
--
2.43.0
Hi Deepanshu,
On 04/05/2026 02:31, Deepanshu Kartikey wrote:
> syzbot reported a KMSAN uninit-value in mptcp_write_data_fin() reached
> via tcp_send_ack() from the subflow shutdown path:
>
> BUG: KMSAN: uninit-value in mptcp_write_data_fin net/mptcp/options.c:542
> mptcp_established_options_dss net/mptcp/options.c:590
> mptcp_established_options net/mptcp/options.c:874
> tcp_established_options net/ipv4/tcp_output.c:1192
> __tcp_transmit_skb net/ipv4/tcp_output.c:1575
> __tcp_send_ack net/ipv4/tcp_output.c:4499
> tcp_send_ack net/ipv4/tcp_output.c:4505
> mptcp_subflow_shutdown net/mptcp/protocol.c:3137
> mptcp_check_send_data_fin net/mptcp/protocol.c:3218
> __mptcp_wr_shutdown net/mptcp/protocol.c:3234
> __mptcp_close net/mptcp/protocol.c:3313
>
> Local variable opts created at:
> __tcp_transmit_skb net/ipv4/tcp_output.c:1536
>
> __tcp_transmit_skb() partially clears its on-stack tcp_out_options via
> "memset(&opts.cleared, ...)" which does not cover opts.mptcp, so MPTCP
> is responsible for initializing opts->ext_copy before use.
>
> mptcp_established_options_dss() only writes opts->ext_copy when an
> MPTCP extension is attached to the skb ("opts->ext_copy = *mpext").
> When tcp_send_ack() builds a fresh pure-ACK skb during subflow
> shutdown, the skb has no extension and that assignment is skipped, but
> the function still calls mptcp_write_data_fin(&opts->ext_copy) because
> snd_data_fin_enable is set. mptcp_write_data_fin() then reads
> ext->use_map to choose between writing a synthetic DATA_FIN mapping or
> extending an existing one, and that read hits uninitialized stack
> memory.
>
> Zero opts->ext_copy at the top of mptcp_established_options_dss() so
> mptcp_write_data_fin() takes its synthetic-mapping branch on clean
> memory.
Thank you for sharing this patch!
Kuniyuki already shared the same patch on the MPTCP ML a few days ago:
https://lore.kernel.org/mptcp/20260501061939.1808489-1-kuniyu@google.com/T/#u
A v2 has been shared a few hours ago:
https://lore.kernel.org/mptcp/20260504044051.3725846-1-kuniyu@google.com/T/#u
(and apparently, a v3 will be needed)
Cheers,
Matt
--
pw-bot: Rejected
Sponsored by the NGI0 Core fund.
Hi Deepanshu,
Thank you for your modifications, that's great!
Our CI did some validations and here is its report:
- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/25295668463
Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/3318919851c0
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1089047
If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:
$ cd [kernel source code]
$ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
--pull always mptcp/mptcp-upstream-virtme-docker:latest \
auto-normal
For more details:
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker
Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)
Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)
© 2016 - 2026 Red Hat, Inc.