Re: [PATCH] mptcp: fix KMSAN: uninit-value in mptcp_established_options

Re: [PATCH] mptcp: fix KMSAN: uninit-value in mptcp_established_options

[Paolo Abeni]

On 5/4/26 11:59 AM, Matthieu Baerts wrote:
> 
> Sorry for the noise: I forgot to add the syzbot instruction... (and I
> forgot to remove the MPTCP ML from the sendmail.to option).

I did not take in account all the possible corner cases.

Let's be a little more conservative.

#syz test
---
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index f7263fe2a2e4..0763fd6f7758 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -27,6 +27,9 @@ struct mptcp_ext {
 	u32		subflow_seq;
 	u16		data_len;
 	__sum16		csum;
+
+	struct_group(flags,
+
 	u8		use_map:1,
 			dsn64:1,
 			data_fin:1,
@@ -38,6 +41,8 @@ struct mptcp_ext {
 	u8		reset_reason:4,
 			csum_reqd:1,
 			infinite_map:1;
+
+	); /* end of flags group */
 };

 #define MPTCPOPT_HMAC_LEN	20
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 8a1c5698983c..3fd40dbff82b 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -572,6 +572,11 @@ static bool mptcp_established_options_dss(struct
sock *sk, struct sk_buff *skb,
 	bool ret = false;
 	u64 ack_seq;

+	/* Zero `can_ack` and `use_map` flags with one shot. */
+	BUILD_BUG_ON(sizeof_field(struct mptcp_ext, flags) != sizeof(u16));
+	BUILD_BUG_ON(!IS_ALIGNED(offsetof(struct mptcp_ext, flags),
+				 sizeof(u16)));
+	*(u16 *)&opts->ext_copy.flags = 0;
 	opts->csum_reqd = READ_ONCE(msk->csum_enabled);
 	mpext = skb ? mptcp_get_ext(skb) : NULL;

@@ -595,7 +600,6 @@ static bool mptcp_established_options_dss(struct
sock *sk, struct sk_buff *skb,
 	/* passive sockets msk will set the 'can_ack' after accept(), even
 	 * if the first subflow may have the already the remote key handy
 	 */
-	opts->ext_copy.use_ack = 0;
 	if (!READ_ONCE(msk->can_ack)) {
 		*size = ALIGN(dss_size, 4);
 		return ret;

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

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to apply patch:
checking file include/net/mptcp.h
checking file net/mptcp/options.c
patch: **** unexpected end of file in patch



Tested on:

commit:         6d35786d Merge tag 'for-linus' of git://git.kernel.org..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=1c3f61154f3bb7e5
dashboard link: https://syzkaller.appspot.com/bug?extid=ff020673c5e3d94d9478
compiler:       
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12558ad2580000

Re: [PATCH] mptcp: fix KMSAN: uninit-value in mptcp_established_options

[Paolo Abeni]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On 5/4/26 6:22 PM, Paolo Abeni wrote:
> On 5/4/26 11:59 AM, Matthieu Baerts wrote:
>>
>> Sorry for the noise: I forgot to add the syzbot instruction... (and I
>> forgot to remove the MPTCP ML from the sendmail.to option).
> 
> I did not take in account all the possible corner cases.
> 
> Let's be a little more conservative.
Darn... the last upgrade here broke the line (un)wrap extension. Let me
attach the patch. Sorry for the spam.

#syz test

[-- Attachment #2: zero_opt_flags.patch --]
[-- Type: text/x-patch, Size: 1455 bytes --]

diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index f7263fe2a2e4..0763fd6f7758 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -27,6 +27,9 @@ struct mptcp_ext {
 	u32		subflow_seq;
 	u16		data_len;
 	__sum16		csum;
+
+	struct_group(flags,
+
 	u8		use_map:1,
 			dsn64:1,
 			data_fin:1,
@@ -38,6 +41,8 @@ struct mptcp_ext {
 	u8		reset_reason:4,
 			csum_reqd:1,
 			infinite_map:1;
+
+	); /* end of flags group */
 };
 
 #define MPTCPOPT_HMAC_LEN	20
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 8a1c5698983c..3fd40dbff82b 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -572,6 +572,11 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
 	bool ret = false;
 	u64 ack_seq;
 
+	/* Zero `can_ack` and `use_map` flags with one shot. */
+	BUILD_BUG_ON(sizeof_field(struct mptcp_ext, flags) != sizeof(u16));
+	BUILD_BUG_ON(!IS_ALIGNED(offsetof(struct mptcp_ext, flags),
+				 sizeof(u16)));
+	*(u16 *)&opts->ext_copy.flags = 0;
 	opts->csum_reqd = READ_ONCE(msk->csum_enabled);
 	mpext = skb ? mptcp_get_ext(skb) : NULL;
 
@@ -595,7 +600,6 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
 	/* passive sockets msk will set the 'can_ack' after accept(), even
 	 * if the first subflow may have the already the remote key handy
 	 */
-	opts->ext_copy.use_ack = 0;
 	if (!READ_ONCE(msk->can_ack)) {
 		*size = ALIGN(dss_size, 4);
 		return ret;

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

[syzbot]

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

=====================================================
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]
 __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
 tcp_data_queue+0x80/0x7c90 net/ipv4/tcp_input.c:5584

CPU: 1 UID: 0 PID: 8009 Comm: syz.0.635 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
=====================================================


Tested on:

commit:         6d35786d Merge tag 'for-linus' of git://git.kernel.org..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10070d06580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=1c3f61154f3bb7e5
dashboard link: https://syzkaller.appspot.com/bug?extid=ff020673c5e3d94d9478
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=13d0b96a580000

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

[Matthieu Baerts]

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?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

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

[Paolo Abeni]

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.

/P

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@googlegroups.com> 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@google.com/T/

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

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

[Matthieu Baerts]

Hi Alexander,

Thank you for your reply!

On 08/05/2026 12:11, Alexander Potapenko wrote:
> On Fri, May 8, 2026 at 11:27 AM 'Paolo Abeni' via syzkaller-bugs
> <syzkaller-bugs@googlegroups.com> 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@google.com/T/

Ah yes, it looks similar.

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

That would be great, thank you!

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

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

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 4203 bytes --]

Hi Alexander,

On 08/05/2026 12:46, Matthieu Baerts wrote:
> Hi Alexander,
> 
> Thank you for your reply!
> 
> On 08/05/2026 12:11, Alexander Potapenko wrote:
>> On Fri, May 8, 2026 at 11:27 AM 'Paolo Abeni' via syzkaller-bugs
>> <syzkaller-bugs@googlegroups.com> 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@google.com/T/
> 
> Ah yes, it looks similar.
> 
>> Let me send the patch, perhaps this issue will also go away.
> 
> That would be great, thank you!

Thank you for having sent your patch.

Here is one combining your modifications, and the ones from Paolo, for
syzbot. If this one is OK, we can continue with Paolo's patch.

#syz test

Cheers,
Matt

[-- Attachment #2: zero_opt_flags_irq_mmi.patch --]
[-- Type: text/x-patch, Size: 2713 bytes --]

diff --git a/include/linux/irq-entry-common.h b/include/linux/irq-entry-common.h
index 167fba7dbf04..be47d430d521 100644
--- a/include/linux/irq-entry-common.h
+++ b/include/linux/irq-entry-common.h
@@ -427,6 +427,7 @@ static __always_inline irqentry_state_t irqentry_enter_from_kernel_mode(struct p
 		ct_irq_enter();
 		instrumentation_begin();
 		kmsan_unpoison_entry_regs(regs);
+		kmsan_unpoison_memory(&ret, sizeof(ret));
 		trace_hardirqs_off_finish();
 		instrumentation_end();
 
@@ -443,6 +444,7 @@ static __always_inline irqentry_state_t irqentry_enter_from_kernel_mode(struct p
 	lockdep_hardirqs_off(CALLER_ADDR0);
 	instrumentation_begin();
 	kmsan_unpoison_entry_regs(regs);
+	kmsan_unpoison_memory(&ret, sizeof(ret));
 	rcu_irq_enter_check_tick();
 	trace_hardirqs_off_finish();
 	instrumentation_end();
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index f7263fe2a2e4..0763fd6f7758 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -27,6 +27,9 @@ struct mptcp_ext {
 	u32		subflow_seq;
 	u16		data_len;
 	__sum16		csum;
+
+	struct_group(flags,
+
 	u8		use_map:1,
 			dsn64:1,
 			data_fin:1,
@@ -38,6 +41,8 @@ struct mptcp_ext {
 	u8		reset_reason:4,
 			csum_reqd:1,
 			infinite_map:1;
+
+	); /* end of flags group */
 };
 
 #define MPTCPOPT_HMAC_LEN	20
diff --git a/kernel/entry/common.c b/kernel/entry/common.c
index 19d2244a9fef..390364943f92 100644
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -177,6 +177,7 @@ irqentry_state_t noinstr irqentry_nmi_enter(struct pt_regs *regs)
 
 	instrumentation_begin();
 	kmsan_unpoison_entry_regs(regs);
+	kmsan_unpoison_memory(&irq_state, sizeof(irq_state));
 	trace_hardirqs_off_finish();
 	ftrace_nmi_enter();
 	instrumentation_end();
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 8a1c5698983c..3fd40dbff82b 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -572,6 +572,11 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
 	bool ret = false;
 	u64 ack_seq;
 
+	/* Zero `can_ack` and `use_map` flags with one shot. */
+	BUILD_BUG_ON(sizeof_field(struct mptcp_ext, flags) != sizeof(u16));
+	BUILD_BUG_ON(!IS_ALIGNED(offsetof(struct mptcp_ext, flags),
+				 sizeof(u16)));
+	*(u16 *)&opts->ext_copy.flags = 0;
 	opts->csum_reqd = READ_ONCE(msk->csum_enabled);
 	mpext = skb ? mptcp_get_ext(skb) : NULL;
 
@@ -595,7 +600,6 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb,
 	/* passive sockets msk will set the 'can_ack' after accept(), even
 	 * if the first subflow may have the already the remote key handy
 	 */
-	opts->ext_copy.use_ack = 0;
 	if (!READ_ONCE(msk->can_ack)) {
 		*size = ALIGN(dss_size, 4);
 		return ret;

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

[Alexander Potapenko]

> >>>> 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@google.com/T/
> >
> > Ah yes, it looks similar.
> >
> >> Let me send the patch, perhaps this issue will also go away.
> >
> > That would be great, thank you!
>
> Thank you for having sent your patch.
>
> Here is one combining your modifications, and the ones from Paolo, for
> syzbot. If this one is OK, we can continue with Paolo's patch.


Hi Matt,

Unfortunately my approach was wrong: see tglx's response there.
Hope we'll figure something out (__no_kmsan_checks looks promising)

Alex

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

[syzbot]

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

=====================================================
BUG: KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt+0xb0/0xc0 include/linux/irq-entry-common.h:474
 irqentry_exit_to_kernel_mode_preempt+0xb0/0xc0 include/linux/irq-entry-common.h:474
 irqentry_exit_to_kernel_mode include/linux/irq-entry-common.h:549 [inline]
 irqentry_exit+0x7b/0x820 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
 __msan_metadata_ptr_for_load_4+0x5/0x40 mm/kmsan/instrumentation.c:93
 tcp_rcv_established+0x19bb/0x3200 net/ipv4/tcp_input.c:6656
 tcp_v4_do_rcv+0xc5b/0x1b70 net/ipv4/tcp_ipv4.c:1851
 sk_backlog_rcv include/net/sock.h:1190 [inline]
 __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/0x1ea0 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
 tcp_data_queue+0x80/0x7c90 net/ipv4/tcp_input.c:5584

CPU: 0 UID: 0 PID: 10313 Comm: syz.0.1815 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
=====================================================


Tested on:

commit:         50897c95 Merge tag 'linux_kselftest-kunit-fixes-7.1-rc..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=121c20c8580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a9f364ffbbe4c1e9
dashboard link: https://syzkaller.appspot.com/bug?extid=ff020673c5e3d94d9478
compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1555c7ce580000

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

[Matthieu Baerts]

Hi Alexander,

On 12/05/2026 11:31, Alexander Potapenko wrote:
>>>>>> 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@google.com/T/
>>>
>>> Ah yes, it looks similar.
>>>
>>>> Let me send the patch, perhaps this issue will also go away.
>>>
>>> That would be great, thank you!
>>
>> Thank you for having sent your patch.
>>
>> Here is one combining your modifications, and the ones from Paolo, for
>> syzbot. If this one is OK, we can continue with Paolo's patch.
> 
> 
> Hi Matt,
> 
> Unfortunately my approach was wrong: see tglx's response there.
> Hope we'll figure something out (__no_kmsan_checks looks promising)
Thank you for your reply, I just found the email thread you mentioned:

  https://lore.kernel.org/all/87v7cu876c.ffs@tglx

If a v2 is not expected "soon", I'm sure we can continue with Paolo's
patch, and double-check later to see if it was enough.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.