Re: [syzbot] [mptcp?] KMSAN: uninit-value in mptcp_established_options

[Alexander Potapenko]

On Fri, May 8, 2026 at 11:27 AM 'Paolo Abeni' via syzkaller-bugs
<syzkaller-bugs@xxxxxxxxxxxxxxxx> wrote:
>
> On 5/7/26 9:44 AM, Matthieu Baerts wrote:
> > Hi Paolo, Kuniyuki,
> >
> > On 04/05/2026 20:20, syzbot wrote:
> >> Hello,
> >>
> >> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> >> KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt
> >
> > It looks like the issue is different now:
> >
> >> =====================================================
> >> BUG: KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt+0xb0/0xc0 include/linux/irq-entry-common.h:472
> >>  irqentry_exit_to_kernel_mode_preempt+0xb0/0xc0 include/linux/irq-entry-common.h:472
> >>  irqentry_exit_to_kernel_mode include/linux/irq-entry-common.h:547 [inline]
> >>  irqentry_exit+0x7b/0x760 kernel/entry/common.c:164
> >>  sysvec_apic_timer_interrupt+0x52/0x90 arch/x86/kernel/apic/apic.c:1061
> >>  asm_sysvec_apic_timer_interrupt+0x1f/0x30 arch/x86/include/asm/idtentry.h:697
> >>  kmsan_get_metadata+0x17/0x160 mm/kmsan/shadow.c:125
> >>  kmsan_get_shadow_origin_ptr+0x4a/0xb0 mm/kmsan/shadow.c:102
> >>  get_shadow_origin_ptr mm/kmsan/instrumentation.c:38 [inline]
> >>  __msan_metadata_ptr_for_load_4+0x24/0x40 mm/kmsan/instrumentation.c:93
> >>  tcp_data_queue+0xdc/0x7c90 net/ipv4/tcp_input.c:5589
> >>  tcp_rcv_established+0x19bb/0x3200 net/ipv4/tcp_input.c:6656
> >>  tcp_v4_do_rcv+0xc4b/0x1b10 net/ipv4/tcp_ipv4.c:1852
> >>  sk_backlog_rcv include/net/sock.h:1190 [inline]
> >
> > That's the input side.
> >
> >>  __release_sock+0x360/0x7d0 net/core/sock.c:3216
> >>  release_sock+0x22d/0x300 net/core/sock.c:3815
> >>  mptcp_subflow_shutdown+0x358/0x690 net/mptcp/protocol.c:3144
> >>  mptcp_check_send_data_fin+0x31b/0x3d0 net/mptcp/protocol.c:3218
> >>  __mptcp_wr_shutdown net/mptcp/protocol.c:3234 [inline]
> >>  __mptcp_close+0x860/0x1360 net/mptcp/protocol.c:3313
> >>  mptcp_close+0x42/0x260 net/mptcp/protocol.c:3367
> >>  inet_release+0x1ee/0x2a0 net/ipv4/af_inet.c:442
> >>  __sock_release net/socket.c:722 [inline]
> >>  sock_close+0xd6/0x2f0 net/socket.c:1514
> >>  __fput+0x60e/0x1010 fs/file_table.c:510
> >>  ____fput+0x25/0x30 fs/file_table.c:538
> >>  task_work_run+0x208/0x2b0 kernel/task_work.c:233
> >>  resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
> >>  __exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
> >>  exit_to_user_mode_loop+0x306/0x1b60 kernel/entry/common.c:98
> >>  __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
> >>  syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
> >>  syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
> >>  do_syscall_64+0x236/0xf80 arch/x86/entry/syscall_64.c:100
> >>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >>
> >> Local variable mp_opt created at:
> >>  mptcp_incoming_options+0x11d/0x43b0 net/mptcp/options.c:1171
> >
> > Confirmed here. With "struct mptcp_options_received" while the original
> > issue was with "struct mptcp_out_options".
> >
> > Plus I'm not exactly sure to understand the issue here: mp_opt is
> > defined and used only in mptcp_incoming_options(), and I don't see
> > anything using it after the end of this function. Or did I miss something?
>
> I also had hard time understanding the backtrace, I think some frames
> are omitted/missing (it happens sometime, IDK why), specifically the one
> related to mptcp_options_received() - which would be useful to
> understand the issue.

This is probably related to
https://lore.kernel.org/all/69e7ee1f.a00a0220.17a17.001d.GAE@xxxxxxxxxx/T/

Let me send the patch, perhaps this issue will also go away.