Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syzkaller: WARNING in mptcp_sendmsg_frag #444

Closed
cpaasch opened this issue Sep 28, 2023 · 7 comments
Closed

syzkaller: WARNING in mptcp_sendmsg_frag #444

cpaasch opened this issue Sep 28, 2023 · 7 comments

Comments

@cpaasch
Copy link
Member

cpaasch commented Sep 28, 2023

syzkaller-id: 05c7ddf5ee57b69d6d9d2cea1420e5e624c2a5a1

HEAD: 331b78e

Trace:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 10691 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc03/0xde0
Modules linked in:
CPU: 0 PID: 10691 Comm: kworker/0:9 Not tainted 6.6.0-rc2-g331b78eb12af #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc03/0xde0 net/mptcp/protocol.c:1312
Code: 63 23 dc fe 48 ff cb 48 89 dd e9 09 fa ff ff e8 53 23 dc fe 0f 0b e9 0d fb ff ff e8 47 23 dc fe e9 1e fc ff ff e8 3d 23 dc fe <0f> 0b e9 a7 f8 ff ff e8 31 23 dc fe e9 2f f8 ff ff f3 0f 1e fa 65
RSP: 0000:ffffc900006fbbe0 EFLAGS: 00010293
RAX: ffffffff8243ca03 RBX: b20668d30234ad5f RCX: ffff888101859e00
RDX: 0000000000000000 RSI: b20668d30234ad5f RDI: b20668d30234ad5f
RBP: b20668d30234ad5e R08: ffffffff8243c290 R09: ffffffff82042b3c
R10: 0000000000000002 R11: ffffffff820564d0 R12: ffff888101e3b900
R13: 0000000000001458 R14: ffff88812e9f8a90 R15: ffff88811a4f5400
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b33724000 CR3: 0000000102176005 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1542
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1611
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3388
 release_sock+0xf6/0x100 net/core/sock.c:3528
 mptcp_worker+0x6eb/0x900 net/mptcp/protocol.c:2743
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>
---[ end trace 0000000000000000 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 10691 at net/mptcp/protocol.c:1341 mptcp_sendmsg_frag+0xbed/0xde0
Modules linked in:
CPU: 0 PID: 10691 Comm: kworker/0:9 Tainted: G        W          6.6.0-rc2-g331b78eb12af #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xbed/0xde0 net/mptcp/protocol.c:1341
Code: e9 a8 fd ff ff e8 73 23 dc fe 48 ff cb 48 89 dd e9 be f9 ff ff e8 63 23 dc fe 48 ff cb 48 89 dd e9 09 fa ff ff e8 53 23 dc fe <0f> 0b e9 0d fb ff ff e8 47 23 dc fe e9 1e fc ff ff e8 3d 23 dc fe
RSP: 0000:ffffc900006fbbe0 EFLAGS: 00010293
RAX: ffffffff8243c9ed RBX: ffff888101e3b900 RCX: ffff888101859e00
RDX: 0000000000000000 RSI: 00000000fffffc0a RDI: 0000000000000001
RBP: 00000000fffffc0a R08: ffffffff8243c2f6 R09: ffffffff82042b3c
R10: 0000000000000002 R11: ffffffff820564d0 R12: 0000000000000001
R13: 0000000000001458 R14: ffff88812e9f8a90 R15: ffff88811a4f5400
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b33724000 CR3: 0000000102176005 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1542
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1611
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3388
 release_sock+0xf6/0x100 net/core/sock.c:3528
 mptcp_worker+0x6eb/0x900 net/mptcp/protocol.c:2743
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>
---[ end trace 0000000000000000 ]---

Kconfig:
Kconfig_k7_clean.txt

No reproducer.

@pabeni
Copy link

pabeni commented Sep 28, 2023

@cpaasch: could you please include the syzkaller log up to e a few progs before the splat itself?

Side note: as a wild guess this looks unrelated to the recent changes

@cpaasch
Copy link
Member Author

cpaasch commented Sep 29, 2023

There you go @pabeni :

23:05:43 executing program 4:
unshare(0x66020400)
r0 = socket$igmp(0x2, 0x3, 0x2)
setsockopt$MRT_ADD_VIF(r0, 0x0, 0xca, &(0x7f0000000240)={0x0, 0x1, 0x0, 0x0, @vifc_lcl_addr=@empty, @multicast2}, 0x10)
r1 = socket$igmp(0x2, 0x3, 0x2)
r2 = socket$inet_icmp_raw(0x2, 0x3, 0x1)
r3 = socket$inet_icmp_raw(0x2, 0x3, 0x1)
setsockopt$inet_group_source_req(r3, 0x0, 0x2e, &(0x7f0000000040)={0xb, {{0x2, 0x0, @multicast2=0xe0000300}}, {{0x2, 0x0, @dev={0xac, 0x14, 0x14, 0x20}}}}, 0x108)
r4 = accept4$inet(r2, &(0x7f00000017c0)={0x2, 0x0, @broadcast}, &(0x7f0000001800)=0x10, 0x80000)
setsockopt$inet_MCAST_MSFILTER(r4, 0x0, 0x30, &(0x7f0000001840)=ANY=[@ANYBLOB="e37300000000000002004e217f000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000900000002004e207f00000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e23ac14143600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e24e00000020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005f41077c779b8c0900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000080a01010200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e22ac1414aa00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e20ac1414bb00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e23ac14143e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e21ac1414aa0000000000000000000000000000000000000000000000000000000000000000000000000000000000bd61000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e20e000000100"/1296], 0x510)
dup2(r2, r3)
r5 = socket$inet_mptcp(0x2, 0x1, 0x106)
r6 = socket$vsock_stream(0x28, 0x1, 0x0)
finit_module(r6, &(0x7f0000001dc0)='socket\x00', 0x1)
setsockopt$inet_tcp_int(r5, 0x6, 0x4, &(0x7f0000001d80)=0x7fff, 0x4)
r7 = socket$igmp(0x2, 0x3, 0x2)
setsockopt$IP_VS_SO_SET_EDITDEST(r3, 0x0, 0x489, &(0x7f0000001740)={{0x21, @initdev={0xac, 0x1e, 0x1, 0x0}, 0x4e23, 0x1, 'lc\x00', 0x20, 0xfffffffb}, {@rand_addr=0x64010102, 0xffff, 0x2, 0xdbf3, 0xfc, 0x6}}, 0x44)
setsockopt$IPT_SO_SET_REPLACE(r7, 0x0, 0x40, &(0x7f0000000280)=@mangle={'mangle\x00', 0x1f, 0x6, 0x1460, 0x1268, 0x1330, 0x11d0, 0x1330, 0x11d0, 0x13c8, 0x13c8, 0x13c8, 0x13c8, 0x13c8, 0x6, &(0x7f0000000180), {[{{@uncond, 0x0, 0x10c8, 0x10f0, 0x0, {}, [@common=@unspec=@cgroup1={{0x1030}, {0x1, 0x1, 0x0, 0x0, './cgroup.cpu/syz0\x00', 0x7fffffff, {0x64}}}, @inet=@rpfilter={{0x28}, {0x4}}]}, @unspec=@CHECKSUM={0x28}}, {{@uncond, 0x0, 0xb8, 0xe0, 0x0, {}, [@inet=@rpfilter={{0x28}, {0x8}}, @common=@socket0={{0x20}}]}, @unspec=@CHECKSUM={0x28}}, {{@uncond, 0x0, 0x70, 0x98}, @unspec=@CHECKSUM={0x28}}, {{@ip={@initdev={0xac, 0x1e, 0x0, 0x0}, @private=0xa010100, 0xff, 0xffffffff, 'rose0\x00', 'veth1\x00', {0xff}, {}, 0x2e, 0x3, 0x2e}, 0x0, 0x98, 0xc8, 0x0, {}, [@inet=@rpfilter={{0x28}}]}, @TPROXY={0x30, 'TPROXY\x00', 0x0, {0x1ff, 0xff, @remote, 0x4e20}}}, {{@ip={@broadcast, @empty, 0x0, 0xffffffff, 'nr0\x00', 'vlan0\x00', {0xff}, {}, 0x5c, 0x1}, 0x0, 0x70, 0x98}, @TTL={0x28, 'TTL\x00', 0x0, {0x2, 0xfc}}}], {{'\x00', 0x0, 0x70, 0x98}, {0x28}}}}, 0x14c0)
setsockopt$inet_group_source_req(r2, 0x0, 0x2e, &(0x7f0000000040)={0xb, {{0x2, 0x0, @multicast2=0xe0000300}}, {{0x2, 0x0, @dev}}}, 0x108)
setsockopt$MRT_DEL_VIF(r1, 0x0, 0xcb, &(0x7f0000000040)={0x0, 0x0, 0x0, 0x0, @vifc_lcl_addr=@initdev={0xac, 0x1e, 0x0, 0x0}, @private}, 0x10)
r8 = socket(0x28, 0x5, 0x0)
connect$unix(r8, &(0x7f00000001c0)=@file={0x1, './file0\x00'}, 0x6e)
setsockopt$MRT_FLUSH(r8, 0x0, 0xd4, &(0x7f0000000000)=0x5, 0x4)

23:05:46 executing program 4:
unshare(0x66020400)
r0 = socket$igmp(0x2, 0x3, 0x2)
setsockopt$MRT_ADD_VIF(r0, 0x0, 0xca, &(0x7f0000000240)={0x0, 0x1, 0x0, 0x0, @vifc_lcl_addr=@empty, @multicast2}, 0x10) (async)
r1 = socket$igmp(0x2, 0x3, 0x2)
r2 = socket$inet_icmp_raw(0x2, 0x3, 0x1) (async)
r3 = socket$inet_icmp_raw(0x2, 0x3, 0x1)
setsockopt$inet_group_source_req(r3, 0x0, 0x2e, &(0x7f0000000040)={0xb, {{0x2, 0x0, @multicast2=0xe0000300}}, {{0x2, 0x0, @dev={0xac, 0x14, 0x14, 0x20}}}}, 0x108) (async)
r4 = accept4$inet(r2, &(0x7f00000017c0)={0x2, 0x0, @broadcast}, &(0x7f0000001800)=0x10, 0x80000)
setsockopt$inet_MCAST_MSFILTER(r4, 0x0, 0x30, &(0x7f0000001840)=ANY=[@ANYBLOB="e37300000000000002004e217f000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000900000002004e207f00000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e23ac14143600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e24e00000020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005f41077c779b8c0900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000080a01010200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e22ac1414aa00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e20ac1414bb00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e23ac14143e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e21ac1414aa0000000000000000000000000000000000000000000000000000000000000000000000000000000000bd61000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e20e000000100"/1296], 0x510) (async)
dup2(r2, r3)
r5 = socket$inet_mptcp(0x2, 0x1, 0x106) (async)
r6 = socket$vsock_stream(0x28, 0x1, 0x0)
finit_module(r6, &(0x7f0000001dc0)='socket\x00', 0x1) (async)
setsockopt$inet_tcp_int(r5, 0x6, 0x4, &(0x7f0000001d80)=0x7fff, 0x4) (async)
r7 = socket$igmp(0x2, 0x3, 0x2)
setsockopt$IP_VS_SO_SET_EDITDEST(r3, 0x0, 0x489, &(0x7f0000001740)={{0x21, @initdev={0xac, 0x1e, 0x1, 0x0}, 0x4e23, 0x1, 'lc\x00', 0x20, 0xfffffffb}, {@rand_addr=0x64010102, 0xffff, 0x2, 0xdbf3, 0xfc, 0x6}}, 0x44) (async, rerun: 64)
setsockopt$IPT_SO_SET_REPLACE(r7, 0x0, 0x40, &(0x7f0000000280)=@mangle={'mangle\x00', 0x1f, 0x6, 0x1460, 0x1268, 0x1330, 0x11d0, 0x1330, 0x11d0, 0x13c8, 0x13c8, 0x13c8, 0x13c8, 0x13c8, 0x6, &(0x7f0000000180), {[{{@uncond, 0x0, 0x10c8, 0x10f0, 0x0, {}, [@common=@unspec=@cgroup1={{0x1030}, {0x1, 0x1, 0x0, 0x0, './cgroup.cpu/syz0\x00', 0x7fffffff, {0x64}}}, @inet=@rpfilter={{0x28}, {0x4}}]}, @unspec=@CHECKSUM={0x28}}, {{@uncond, 0x0, 0xb8, 0xe0, 0x0, {}, [@inet=@rpfilter={{0x28}, {0x8}}, @common=@socket0={{0x20}}]}, @unspec=@CHECKSUM={0x28}}, {{@uncond, 0x0, 0x70, 0x98}, @unspec=@CHECKSUM={0x28}}, {{@ip={@initdev={0xac, 0x1e, 0x0, 0x0}, @private=0xa010100, 0xff, 0xffffffff, 'rose0\x00', 'veth1\x00', {0xff}, {}, 0x2e, 0x3, 0x2e}, 0x0, 0x98, 0xc8, 0x0, {}, [@inet=@rpfilter={{0x28}}]}, @TPROXY={0x30, 'TPROXY\x00', 0x0, {0x1ff, 0xff, @remote, 0x4e20}}}, {{@ip={@broadcast, @empty, 0x0, 0xffffffff, 'nr0\x00', 'vlan0\x00', {0xff}, {}, 0x5c, 0x1}, 0x0, 0x70, 0x98}, @TTL={0x28, 'TTL\x00', 0x0, {0x2, 0xfc}}}], {{'\x00', 0x0, 0x70, 0x98}, {0x28}}}}, 0x14c0) (async, rerun: 64)
setsockopt$inet_group_source_req(r2, 0x0, 0x2e, &(0x7f0000000040)={0xb, {{0x2, 0x0, @multicast2=0xe0000300}}, {{0x2, 0x0, @dev}}}, 0x108)
setsockopt$MRT_DEL_VIF(r1, 0x0, 0xcb, &(0x7f0000000040)={0x0, 0x0, 0x0, 0x0, @vifc_lcl_addr=@initdev={0xac, 0x1e, 0x0, 0x0}, @private}, 0x10) (async, rerun: 64)
r8 = socket(0x28, 0x5, 0x0) (rerun: 64)
connect$unix(r8, &(0x7f00000001c0)=@file={0x1, './file0\x00'}, 0x6e)
setsockopt$MRT_FLUSH(r8, 0x0, 0xd4, &(0x7f0000000000)=0x5, 0x4)

23:05:46 executing program 4:
unshare(0x66020400)
r0 = socket$igmp(0x2, 0x3, 0x2)
setsockopt$MRT_ADD_VIF(r0, 0x0, 0xca, &(0x7f0000000240)={0x0, 0x1, 0x0, 0x0, @vifc_lcl_addr=@empty, @multicast2}, 0x10) (async)
r1 = socket$igmp(0x2, 0x3, 0x2)
r2 = socket$inet_icmp_raw(0x2, 0x3, 0x1)
r3 = socket$inet_icmp_raw(0x2, 0x3, 0x1)
setsockopt$inet_group_source_req(r3, 0x0, 0x2e, &(0x7f0000000040)={0xb, {{0x2, 0x0, @multicast2=0xe0000300}}, {{0x2, 0x0, @dev={0xac, 0x14, 0x14, 0x20}}}}, 0x108) (async)
r4 = accept4$inet(r2, &(0x7f00000017c0)={0x2, 0x0, @broadcast}, &(0x7f0000001800)=0x10, 0x80000)
setsockopt$inet_MCAST_MSFILTER(r4, 0x0, 0x30, &(0x7f0000001840)=ANY=[@ANYBLOB="e37300000000000002004e217f000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000900000002004e207f00000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e23ac14143600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e24e00000020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005f41077c779b8c0900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000080a01010200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e22ac1414aa00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e20ac1414bb00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e23ac14143e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e21ac1414aa0000000000000000000000000000000000000000000000000000000000000000000000000000000000bd61000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002004e20e000000100"/1296], 0x510) (async)
dup2(r2, r3)
r5 = socket$inet_mptcp(0x2, 0x1, 0x106)
r6 = socket$vsock_stream(0x28, 0x1, 0x0)
finit_module(r6, &(0x7f0000001dc0)='socket\x00', 0x1) (async)
setsockopt$inet_tcp_int(r5, 0x6, 0x4, &(0x7f0000001d80)=0x7fff, 0x4) (async, rerun: 64)
r7 = socket$igmp(0x2, 0x3, 0x2) (async, rerun: 64)
setsockopt$IP_VS_SO_SET_EDITDEST(r3, 0x0, 0x489, &(0x7f0000001740)={{0x21, @initdev={0xac, 0x1e, 0x1, 0x0}, 0x4e23, 0x1, 'lc\x00', 0x20, 0xfffffffb}, {@rand_addr=0x64010102, 0xffff, 0x2, 0xdbf3, 0xfc, 0x6}}, 0x44)
setsockopt$IPT_SO_SET_REPLACE(r7, 0x0, 0x40, &(0x7f0000000280)=@mangle={'mangle\x00', 0x1f, 0x6, 0x1460, 0x1268, 0x1330, 0x11d0, 0x1330, 0x11d0, 0x13c8, 0x13c8, 0x13c8, 0x13c8, 0x13c8, 0x6, &(0x7f0000000180), {[{{@uncond, 0x0, 0x10c8, 0x10f0, 0x0, {}, [@common=@unspec=@cgroup1={{0x1030}, {0x1, 0x1, 0x0, 0x0, './cgroup.cpu/syz0\x00', 0x7fffffff, {0x64}}}, @inet=@rpfilter={{0x28}, {0x4}}]}, @unspec=@CHECKSUM={0x28}}, {{@uncond, 0x0, 0xb8, 0xe0, 0x0, {}, [@inet=@rpfilter={{0x28}, {0x8}}, @common=@socket0={{0x20}}]}, @unspec=@CHECKSUM={0x28}}, {{@uncond, 0x0, 0x70, 0x98}, @unspec=@CHECKSUM={0x28}}, {{@ip={@initdev={0xac, 0x1e, 0x0, 0x0}, @private=0xa010100, 0xff, 0xffffffff, 'rose0\x00', 'veth1\x00', {0xff}, {}, 0x2e, 0x3, 0x2e}, 0x0, 0x98, 0xc8, 0x0, {}, [@inet=@rpfilter={{0x28}}]}, @TPROXY={0x30, 'TPROXY\x00', 0x0, {0x1ff, 0xff, @remote, 0x4e20}}}, {{@ip={@broadcast, @empty, 0x0, 0xffffffff, 'nr0\x00', 'vlan0\x00', {0xff}, {}, 0x5c, 0x1}, 0x0, 0x70, 0x98}, @TTL={0x28, 'TTL\x00', 0x0, {0x2, 0xfc}}}], {{'\x00', 0x0, 0x70, 0x98}, {0x28}}}}, 0x14c0) (async, rerun: 32)
setsockopt$inet_group_source_req(r2, 0x0, 0x2e, &(0x7f0000000040)={0xb, {{0x2, 0x0, @multicast2=0xe0000300}}, {{0x2, 0x0, @dev}}}, 0x108) (rerun: 32)
setsockopt$MRT_DEL_VIF(r1, 0x0, 0xcb, &(0x7f0000000040)={0x0, 0x0, 0x0, 0x0, @vifc_lcl_addr=@initdev={0xac, 0x1e, 0x0, 0x0}, @private}, 0x10) (async)
r8 = socket(0x28, 0x5, 0x0)
connect$unix(r8, &(0x7f00000001c0)=@file={0x1, './file0\x00'}, 0x6e) (async, rerun: 32)
setsockopt$MRT_FLUSH(r8, 0x0, 0xd4, &(0x7f0000000000)=0x5, 0x4) (rerun: 32)

23:05:47 executing program 2:
pipe2$watch_queue(&(0x7f0000000000)={0xffffffffffffffff, <r0=>0xffffffffffffffff}, 0x80)
r1 = syz_genetlink_get_family_id$mptcp(&(0x7f0000000140), 0xffffffffffffffff)
ioctl$sock_ipv4_tunnel_SIOCCHGTUNNEL(0xffffffffffffffff, 0x89f3, &(0x7f0000000240)={'syztnl1\x00', &(0x7f0000000180)=ANY=[@ANYBLOB='gre0\x00'/16, @ANYRES32=<r2=>0x0, @ANYBLOB="0700008080000000002033dc4d0800740065000005049078ac141425ffffffff441c4a700000fca40000040180000001000002620000083b00000200440c3df3ac1e000100000003004434e433ffffffff00000001ac1414170000067aac1414bb000000016401010100000009e000000100000001e000000200000006830344"]})
sendmsg$MPTCP_PM_CMD_SUBFLOW_DESTROY(r0, &(0x7f00000003c0)={&(0x7f0000000100)={0x10, 0x0, 0x0, 0x40000000}, 0xc, &(0x7f0000000380)={&(0x7f0000000280)={0xfc, r1, 0x400, 0x70bd28, 0x25dfdbfd, {}, [@MPTCP_PM_ATTR_ADDR_REMOTE={0x54, 0x6, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_ADDR4={0x8, 0x3, @empty}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e20}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @private0}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0xa}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @mcast2}]}, @MPTCP_PM_ATTR_TOKEN={0x8, 0x4, 0x9}, @MPTCP_PM_ATTR_RCV_ADD_ADDRS={0x8}, @MPTCP_PM_ATTR_ADDR_REMOTE={0x48, 0x6, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @initdev={0xfe, 0x88, '\x00', 0x1, 0x0}}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e21}, @MPTCP_PM_ADDR_ATTR_ADDR4={0x8, 0x3, @loopback}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_IF_IDX={0x8}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8, 0x6, 0xf}]}, @MPTCP_PM_ATTR_ADDR={0x3c, 0x1, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_ID={0x5, 0x2, 0x3f}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8, 0x6, 0x9}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e20}, @MPTCP_PM_ADDR_ATTR_IF_IDX={0x8, 0x7, r2}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e23}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e24}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0xa}]}]}, 0xfc}, 0x1, 0x0, 0x0, 0x10001}, 0x1)
r3 = syz_open_dev$loop(&(0x7f0000000040), 0x0, 0x0)
ioctl$BLKTRACESTOP(r3, 0x2, 0x200000000000000)
ioctl$BLKTRACESETUP(r3, 0xc0481273, &(0x7f0000000080)={'\x00', 0x4, 0x3, 0x100, 0xffffffffffffffff, 0x287})
r4 = open_tree(r0, &(0x7f0000000440)='./file0\x00', 0x1000)
ioctl$LOOP_CHANGE_FD(r4, 0x4c06, 0xffffffffffffffff)
r5 = socket$nl_netfilter(0x10, 0x3, 0xc)
r6 = dup2(r5, r5)
sendmsg$NFT_MSG_GETRULE(r6, &(0x7f0000000000)={0x0, 0x0, &(0x7f0000000400)={&(0x7f00000002c0)={0x14, 0x7, 0xa, 0x301}, 0x14}}, 0x0)
ioctl$BLKTRACESTART(r6, 0x1274, 0x0)

23:05:47 executing program 2:
pipe2$watch_queue(&(0x7f0000000000)={0xffffffffffffffff, <r0=>0xffffffffffffffff}, 0x80) (async)
r1 = syz_genetlink_get_family_id$mptcp(&(0x7f0000000140), 0xffffffffffffffff)
ioctl$sock_ipv4_tunnel_SIOCCHGTUNNEL(0xffffffffffffffff, 0x89f3, &(0x7f0000000240)={'syztnl1\x00', &(0x7f0000000180)=ANY=[@ANYBLOB='gre0\x00'/16, @ANYRES32=<r2=>0x0, @ANYBLOB="0700008080000000002033dc4d0800740065000005049078ac141425ffffffff441c4a700000fca40000040180000001000002620000083b00000200440c3df3ac1e000100000003004434e433ffffffff00000001ac1414170000067aac1414bb000000016401010100000009e000000100000001e000000200000006830344"]}) (async)
sendmsg$MPTCP_PM_CMD_SUBFLOW_DESTROY(r0, &(0x7f00000003c0)={&(0x7f0000000100)={0x10, 0x0, 0x0, 0x40000000}, 0xc, &(0x7f0000000380)={&(0x7f0000000280)={0xfc, r1, 0x400, 0x70bd28, 0x25dfdbfd, {}, [@MPTCP_PM_ATTR_ADDR_REMOTE={0x54, 0x6, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_ADDR4={0x8, 0x3, @empty}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e20}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @private0}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0xa}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @mcast2}]}, @MPTCP_PM_ATTR_TOKEN={0x8, 0x4, 0x9}, @MPTCP_PM_ATTR_RCV_ADD_ADDRS={0x8}, @MPTCP_PM_ATTR_ADDR_REMOTE={0x48, 0x6, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @initdev={0xfe, 0x88, '\x00', 0x1, 0x0}}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e21}, @MPTCP_PM_ADDR_ATTR_ADDR4={0x8, 0x3, @loopback}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_IF_IDX={0x8}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8, 0x6, 0xf}]}, @MPTCP_PM_ATTR_ADDR={0x3c, 0x1, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_ID={0x5, 0x2, 0x3f}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8, 0x6, 0x9}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e20}, @MPTCP_PM_ADDR_ATTR_IF_IDX={0x8, 0x7, r2}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e23}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e24}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0xa}]}]}, 0xfc}, 0x1, 0x0, 0x0, 0x10001}, 0x1)
r3 = syz_open_dev$loop(&(0x7f0000000040), 0x0, 0x0)
ioctl$BLKTRACESTOP(r3, 0x2, 0x200000000000000) (async)
ioctl$BLKTRACESETUP(r3, 0xc0481273, &(0x7f0000000080)={'\x00', 0x4, 0x3, 0x100, 0xffffffffffffffff, 0x287})
r4 = open_tree(r0, &(0x7f0000000440)='./file0\x00', 0x1000)
ioctl$LOOP_CHANGE_FD(r4, 0x4c06, 0xffffffffffffffff) (async)
r5 = socket$nl_netfilter(0x10, 0x3, 0xc)
r6 = dup2(r5, r5)
sendmsg$NFT_MSG_GETRULE(r6, &(0x7f0000000000)={0x0, 0x0, &(0x7f0000000400)={&(0x7f00000002c0)={0x14, 0x7, 0xa, 0x301}, 0x14}}, 0x0) (async)
ioctl$BLKTRACESTART(r6, 0x1274, 0x0)

23:05:47 executing program 2:
pipe2$watch_queue(&(0x7f0000000000)={0xffffffffffffffff, <r0=>0xffffffffffffffff}, 0x80)
r1 = syz_genetlink_get_family_id$mptcp(&(0x7f0000000140), 0xffffffffffffffff) (async)
ioctl$sock_ipv4_tunnel_SIOCCHGTUNNEL(0xffffffffffffffff, 0x89f3, &(0x7f0000000240)={'syztnl1\x00', &(0x7f0000000180)=ANY=[@ANYBLOB='gre0\x00'/16, @ANYRES32=<r2=>0x0, @ANYBLOB="0700008080000000002033dc4d0800740065000005049078ac141425ffffffff441c4a700000fca40000040180000001000002620000083b00000200440c3df3ac1e000100000003004434e433ffffffff00000001ac1414170000067aac1414bb000000016401010100000009e000000100000001e000000200000006830344"]})
sendmsg$MPTCP_PM_CMD_SUBFLOW_DESTROY(r0, &(0x7f00000003c0)={&(0x7f0000000100)={0x10, 0x0, 0x0, 0x40000000}, 0xc, &(0x7f0000000380)={&(0x7f0000000280)={0xfc, r1, 0x400, 0x70bd28, 0x25dfdbfd, {}, [@MPTCP_PM_ATTR_ADDR_REMOTE={0x54, 0x6, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_ADDR4={0x8, 0x3, @empty}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e20}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @private0}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0xa}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @mcast2}]}, @MPTCP_PM_ATTR_TOKEN={0x8, 0x4, 0x9}, @MPTCP_PM_ATTR_RCV_ADD_ADDRS={0x8}, @MPTCP_PM_ATTR_ADDR_REMOTE={0x48, 0x6, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_ADDR6={0x14, 0x4, @initdev={0xfe, 0x88, '\x00', 0x1, 0x0}}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e21}, @MPTCP_PM_ADDR_ATTR_ADDR4={0x8, 0x3, @loopback}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}, @MPTCP_PM_ADDR_ATTR_IF_IDX={0x8}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8, 0x6, 0xf}]}, @MPTCP_PM_ATTR_ADDR={0x3c, 0x1, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_ID={0x5, 0x2, 0x3f}, @MPTCP_PM_ADDR_ATTR_FLAGS={0x8, 0x6, 0x9}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e20}, @MPTCP_PM_ADDR_ATTR_IF_IDX={0x8, 0x7, r2}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e23}, @MPTCP_PM_ADDR_ATTR_PORT={0x6, 0x5, 0x4e24}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0xa}]}]}, 0xfc}, 0x1, 0x0, 0x0, 0x10001}, 0x1) (async)
r3 = syz_open_dev$loop(&(0x7f0000000040), 0x0, 0x0)
ioctl$BLKTRACESTOP(r3, 0x2, 0x200000000000000) (async)
ioctl$BLKTRACESETUP(r3, 0xc0481273, &(0x7f0000000080)={'\x00', 0x4, 0x3, 0x100, 0xffffffffffffffff, 0x287}) (async)
r4 = open_tree(r0, &(0x7f0000000440)='./file0\x00', 0x1000)
ioctl$LOOP_CHANGE_FD(r4, 0x4c06, 0xffffffffffffffff) (async)
r5 = socket$nl_netfilter(0x10, 0x3, 0xc)
r6 = dup2(r5, r5)
sendmsg$NFT_MSG_GETRULE(r6, &(0x7f0000000000)={0x0, 0x0, &(0x7f0000000400)={&(0x7f00000002c0)={0x14, 0x7, 0xa, 0x301}, 0x14}}, 0x0)
ioctl$BLKTRACESTART(r6, 0x1274, 0x0)

23:05:48 executing program 4:
r0 = socket$inet_mptcp(0x2, 0x1, 0x106)
r1 = dup(r0)
setsockopt$inet_tcp_int(r0, 0x6, 0x22, &(0x7f0000000000)=0x1, 0x4)
bind$inet(r0, &(0x7f00000011c0)={0x2, 0x4e22, @loopback}, 0x2)
sendmmsg$inet(r1, &(0x7f0000001ac0)=[{{&(0x7f0000000040)={0x2, 0x4e23, @local}, 0x10, &(0x7f0000000440)=[{&(0x7f0000000100)="c2", 0x1}], 0x1}}], 0x1, 0x2400c05f)
setsockopt$inet_tcp_TCP_CONGESTION(r0, 0x6, 0xd, &(0x7f00000002c0)='cdg\x00', 0x4)
r2 = socket$unix(0x1, 0x5, 0x0)
r3 = socket$inet6(0xa, 0x1, 0x0)
bind$unix(r2, &(0x7f0000000140)=@file={0x1, './file0\x00'}, 0x6e)
dup3(r2, r3, 0x0)
recvmmsg(r2, &(0x7f0000004440)=[{{&(0x7f0000000080)=@pppol2tp={0x18, 0x1, {0x0, 0xffffffffffffffff, {0x2, 0x0, @empty}}}, 0x80, &(0x7f0000000240)=[{&(0x7f0000000140)=""/67, 0x43}, {&(0x7f00000001c0)=""/101, 0x65}, {&(0x7f0000001b00)=""/4096, 0x1000}, {&(0x7f0000000300)=""/225, 0xe1}], 0x4, &(0x7f0000000280)}, 0x1ff}, {{0x0, 0x0, &(0x7f0000000400)=[{&(0x7f0000000480)=""/247, 0xf7}], 0x1, &(0x7f0000000580)=""/70, 0x46}, 0x800}, {{&(0x7f0000000600)=@alg, 0x80, &(0x7f0000000d80)=[{&(0x7f0000000680)=""/57, 0x39}, {&(0x7f00000006c0)=""/133, 0x85}, {&(0x7f0000000780)=""/199, 0xc7}, {&(0x7f0000000880)=""/204, 0xcc}, {&(0x7f0000000980)=""/200, 0xc8}, {&(0x7f0000000a80)=""/110, 0x6e}, {&(0x7f0000000b00)=""/145, 0x91}, {&(0x7f0000000bc0)=""/108, 0x6c}, {&(0x7f0000000c40)=""/239, 0xef}, {&(0x7f0000000d40)=""/52, 0x34}], 0xa}, 0xffffffff}, {{&(0x7f0000000e40)=@in6={0xa, 0x0, 0x0, @mcast1}, 0x80, &(0x7f0000001400)=[{&(0x7f0000000ec0)=""/82, 0x52}, {&(0x7f0000000f40)=""/211, 0xd3}, {&(0x7f0000001040)=""/152, 0x98}, {&(0x7f0000001200)=""/241, 0xf1}, {&(0x7f0000001100)=""/6, 0x6}, {&(0x7f0000001300)=""/244, 0xf4}, {&(0x7f0000001140)=""/14, 0xe}, {&(0x7f0000001180)=""/54, 0x36}], 0x8, &(0x7f0000002b00)=""/4096, 0x1000}, 0xff}, {{0x0, 0x0, &(0x7f0000001840)=[{&(0x7f0000001480)=""/208, 0xd0}, {&(0x7f0000001580)=""/183, 0xb7}, {&(0x7f0000001640)=""/23, 0x17}, {&(0x7f0000001680)=""/216, 0xd8}, {&(0x7f0000001780)=""/185, 0xb9}], 0x5, &(0x7f00000018c0)=""/151, 0x97}, 0x81}, {{&(0x7f0000001980)=@pptp={0x18, 0x2, {0x0, @empty}}, 0x80, &(0x7f0000001a00)}, 0x3}, {{&(0x7f0000001a40)=@hci, 0x80, &(0x7f0000004200)=[{&(0x7f0000003b00)=""/98, 0x62}, {&(0x7f0000003b80)=""/136, 0x88}, {&(0x7f0000003c40)=""/123, 0x7b}, {&(0x7f0000003cc0)=""/167, 0xa7}, {&(0x7f0000003d80)=""/70, 0x46}, {&(0x7f0000003e00)=""/181, 0xb5}, {&(0x7f0000003ec0)=""/203, 0xcb}, {&(0x7f0000003fc0)=""/120, 0x78}, {&(0x7f0000004040)=""/182, 0xb6}, {&(0x7f0000004100)=""/247, 0xf7}], 0xa, &(0x7f00000042c0)=""/88, 0x58}, 0xffffff62}, {{&(0x7f0000004340)=@hci, 0x80, &(0x7f00000043c0), 0x0, &(0x7f0000004400)=""/10, 0xa}, 0x7}], 0x8, 0x120, 0x0)
shutdown(r0, 0x1)

23:05:48 executing program 4:
r0 = socket$inet_mptcp(0x2, 0x1, 0x106)
r1 = dup(r0)
setsockopt$inet_tcp_int(r0, 0x6, 0x22, &(0x7f0000000000)=0x1, 0x4)
bind$inet(r0, &(0x7f00000011c0)={0x2, 0x4e22, @loopback}, 0x2)
sendmmsg$inet(r1, &(0x7f0000001ac0)=[{{&(0x7f0000000040)={0x2, 0x4e23, @local}, 0x10, &(0x7f0000000440)=[{&(0x7f0000000100)="c2", 0x1}], 0x1}}], 0x1, 0x2400c05f)
setsockopt$inet_tcp_TCP_CONGESTION(r0, 0x6, 0xd, &(0x7f00000002c0)='cdg\x00', 0x4)
r2 = socket$unix(0x1, 0x5, 0x0)
r3 = socket$inet6(0xa, 0x1, 0x0)
bind$unix(r2, &(0x7f0000000140)=@file={0x1, './file0\x00'}, 0x6e)
dup3(r2, r3, 0x0)
recvmmsg(r2, &(0x7f0000004440)=[{{&(0x7f0000000080)=@pppol2tp={0x18, 0x1, {0x0, 0xffffffffffffffff, {0x2, 0x0, @empty}}}, 0x80, &(0x7f0000000240)=[{&(0x7f0000000140)=""/67, 0x43}, {&(0x7f00000001c0)=""/101, 0x65}, {&(0x7f0000001b00)=""/4096, 0x1000}, {&(0x7f0000000300)=""/225, 0xe1}], 0x4, &(0x7f0000000280)}, 0x1ff}, {{0x0, 0x0, &(0x7f0000000400)=[{&(0x7f0000000480)=""/247, 0xf7}], 0x1, &(0x7f0000000580)=""/70, 0x46}, 0x800}, {{&(0x7f0000000600)=@alg, 0x80, &(0x7f0000000d80)=[{&(0x7f0000000680)=""/57, 0x39}, {&(0x7f00000006c0)=""/133, 0x85}, {&(0x7f0000000780)=""/199, 0xc7}, {&(0x7f0000000880)=""/204, 0xcc}, {&(0x7f0000000980)=""/200, 0xc8}, {&(0x7f0000000a80)=""/110, 0x6e}, {&(0x7f0000000b00)=""/145, 0x91}, {&(0x7f0000000bc0)=""/108, 0x6c}, {&(0x7f0000000c40)=""/239, 0xef}, {&(0x7f0000000d40)=""/52, 0x34}], 0xa}, 0xffffffff}, {{&(0x7f0000000e40)=@in6={0xa, 0x0, 0x0, @mcast1}, 0x80, &(0x7f0000001400)=[{&(0x7f0000000ec0)=""/82, 0x52}, {&(0x7f0000000f40)=""/211, 0xd3}, {&(0x7f0000001040)=""/152, 0x98}, {&(0x7f0000001200)=""/241, 0xf1}, {&(0x7f0000001100)=""/6, 0x6}, {&(0x7f0000001300)=""/244, 0xf4}, {&(0x7f0000001140)=""/14, 0xe}, {&(0x7f0000001180)=""/54, 0x36}], 0x8, &(0x7f0000002b00)=""/4096, 0x1000}, 0xff}, {{0x0, 0x0, &(0x7f0000001840)=[{&(0x7f0000001480)=""/208, 0xd0}, {&(0x7f0000001580)=""/183, 0xb7}, {&(0x7f0000001640)=""/23, 0x17}, {&(0x7f0000001680)=""/216, 0xd8}, {&(0x7f0000001780)=""/185, 0xb9}], 0x5, &(0x7f00000018c0)=""/151, 0x97}, 0x81}, {{&(0x7f0000001980)=@pptp={0x18, 0x2, {0x0, @empty}}, 0x80, &(0x7f0000001a00)}, 0x3}, {{&(0x7f0000001a40)=@hci, 0x80, &(0x7f0000004200)=[{&(0x7f0000003b00)=""/98, 0x62}, {&(0x7f0000003b80)=""/136, 0x88}, {&(0x7f0000003c40)=""/123, 0x7b}, {&(0x7f0000003cc0)=""/167, 0xa7}, {&(0x7f0000003d80)=""/70, 0x46}, {&(0x7f0000003e00)=""/181, 0xb5}, {&(0x7f0000003ec0)=""/203, 0xcb}, {&(0x7f0000003fc0)=""/120, 0x78}, {&(0x7f0000004040)=""/182, 0xb6}, {&(0x7f0000004100)=""/247, 0xf7}], 0xa, &(0x7f00000042c0)=""/88, 0x58}, 0xffffff62}, {{&(0x7f0000004340)=@hci, 0x80, &(0x7f00000043c0), 0x0, &(0x7f0000004400)=""/10, 0xa}, 0x7}], 0x8, 0x120, 0x0)
shutdown(r0, 0x1)
socket$inet_mptcp(0x2, 0x1, 0x106) (async)
dup(r0) (async)
setsockopt$inet_tcp_int(r0, 0x6, 0x22, &(0x7f0000000000)=0x1, 0x4) (async)
bind$inet(r0, &(0x7f00000011c0)={0x2, 0x4e22, @loopback}, 0x2) (async)
sendmmsg$inet(r1, &(0x7f0000001ac0)=[{{&(0x7f0000000040)={0x2, 0x4e23, @local}, 0x10, &(0x7f0000000440)=[{&(0x7f0000000100)="c2", 0x1}], 0x1}}], 0x1, 0x2400c05f) (async)
setsockopt$inet_tcp_TCP_CONGESTION(r0, 0x6, 0xd, &(0x7f00000002c0)='cdg\x00', 0x4) (async)
socket$unix(0x1, 0x5, 0x0) (async)
socket$inet6(0xa, 0x1, 0x0) (async)
bind$unix(r2, &(0x7f0000000140)=@file={0x1, './file0\x00'}, 0x6e) (async)
dup3(r2, r3, 0x0) (async)
recvmmsg(r2, &(0x7f0000004440)=[{{&(0x7f0000000080)=@pppol2tp={0x18, 0x1, {0x0, 0xffffffffffffffff, {0x2, 0x0, @empty}}}, 0x80, &(0x7f0000000240)=[{&(0x7f0000000140)=""/67, 0x43}, {&(0x7f00000001c0)=""/101, 0x65}, {&(0x7f0000001b00)=""/4096, 0x1000}, {&(0x7f0000000300)=""/225, 0xe1}], 0x4, &(0x7f0000000280)}, 0x1ff}, {{0x0, 0x0, &(0x7f0000000400)=[{&(0x7f0000000480)=""/247, 0xf7}], 0x1, &(0x7f0000000580)=""/70, 0x46}, 0x800}, {{&(0x7f0000000600)=@alg, 0x80, &(0x7f0000000d80)=[{&(0x7f0000000680)=""/57, 0x39}, {&(0x7f00000006c0)=""/133, 0x85}, {&(0x7f0000000780)=""/199, 0xc7}, {&(0x7f0000000880)=""/204, 0xcc}, {&(0x7f0000000980)=""/200, 0xc8}, {&(0x7f0000000a80)=""/110, 0x6e}, {&(0x7f0000000b00)=""/145, 0x91}, {&(0x7f0000000bc0)=""/108, 0x6c}, {&(0x7f0000000c40)=""/239, 0xef}, {&(0x7f0000000d40)=""/52, 0x34}], 0xa}, 0xffffffff}, {{&(0x7f0000000e40)=@in6={0xa, 0x0, 0x0, @mcast1}, 0x80, &(0x7f0000001400)=[{&(0x7f0000000ec0)=""/82, 0x52}, {&(0x7f0000000f40)=""/211, 0xd3}, {&(0x7f0000001040)=""/152, 0x98}, {&(0x7f0000001200)=""/241, 0xf1}, {&(0x7f0000001100)=""/6, 0x6}, {&(0x7f0000001300)=""/244, 0xf4}, {&(0x7f0000001140)=""/14, 0xe}, {&(0x7f0000001180)=""/54, 0x36}], 0x8, &(0x7f0000002b00)=""/4096, 0x1000}, 0xff}, {{0x0, 0x0, &(0x7f0000001840)=[{&(0x7f0000001480)=""/208, 0xd0}, {&(0x7f0000001580)=""/183, 0xb7}, {&(0x7f0000001640)=""/23, 0x17}, {&(0x7f0000001680)=""/216, 0xd8}, {&(0x7f0000001780)=""/185, 0xb9}], 0x5, &(0x7f00000018c0)=""/151, 0x97}, 0x81}, {{&(0x7f0000001980)=@pptp={0x18, 0x2, {0x0, @empty}}, 0x80, &(0x7f0000001a00)}, 0x3}, {{&(0x7f0000001a40)=@hci, 0x80, &(0x7f0000004200)=[{&(0x7f0000003b00)=""/98, 0x62}, {&(0x7f0000003b80)=""/136, 0x88}, {&(0x7f0000003c40)=""/123, 0x7b}, {&(0x7f0000003cc0)=""/167, 0xa7}, {&(0x7f0000003d80)=""/70, 0x46}, {&(0x7f0000003e00)=""/181, 0xb5}, {&(0x7f0000003ec0)=""/203, 0xcb}, {&(0x7f0000003fc0)=""/120, 0x78}, {&(0x7f0000004040)=""/182, 0xb6}, {&(0x7f0000004100)=""/247, 0xf7}], 0xa, &(0x7f00000042c0)=""/88, 0x58}, 0xffffff62}, {{&(0x7f0000004340)=@hci, 0x80, &(0x7f00000043c0), 0x0, &(0x7f0000004400)=""/10, 0xa}, 0x7}], 0x8, 0x120, 0x0) (async)
shutdown(r0, 0x1) (async)


23:05:48 executing program 4:
r0 = socket$inet_mptcp(0x2, 0x1, 0x106)
r1 = dup(r0)
setsockopt$inet_tcp_int(r0, 0x6, 0x22, &(0x7f0000000000)=0x1, 0x4) (async)
bind$inet(r0, &(0x7f00000011c0)={0x2, 0x4e22, @loopback}, 0x2) (async)
sendmmsg$inet(r1, &(0x7f0000001ac0)=[{{&(0x7f0000000040)={0x2, 0x4e23, @local}, 0x10, &(0x7f0000000440)=[{&(0x7f0000000100)="c2", 0x1}], 0x1}}], 0x1, 0x2400c05f)
setsockopt$inet_tcp_TCP_CONGESTION(r0, 0x6, 0xd, &(0x7f00000002c0)='cdg\x00', 0x4) (async)
r2 = socket$unix(0x1, 0x5, 0x0) (async)
r3 = socket$inet6(0xa, 0x1, 0x0)
bind$unix(r2, &(0x7f0000000140)=@file={0x1, './file0\x00'}, 0x6e) (async)
dup3(r2, r3, 0x0) (async)
recvmmsg(r2, &(0x7f0000004440)=[{{&(0x7f0000000080)=@pppol2tp={0x18, 0x1, {0x0, 0xffffffffffffffff, {0x2, 0x0, @empty}}}, 0x80, &(0x7f0000000240)=[{&(0x7f0000000140)=""/67, 0x43}, {&(0x7f00000001c0)=""/101, 0x65}, {&(0x7f0000001b00)=""/4096, 0x1000}, {&(0x7f0000000300)=""/225, 0xe1}], 0x4, &(0x7f0000000280)}, 0x1ff}, {{0x0, 0x0, &(0x7f0000000400)=[{&(0x7f0000000480)=""/247, 0xf7}], 0x1, &(0x7f0000000580)=""/70, 0x46}, 0x800}, {{&(0x7f0000000600)=@alg, 0x80, &(0x7f0000000d80)=[{&(0x7f0000000680)=""/57, 0x39}, {&(0x7f00000006c0)=""/133, 0x85}, {&(0x7f0000000780)=""/199, 0xc7}, {&(0x7f0000000880)=""/204, 0xcc}, {&(0x7f0000000980)=""/200, 0xc8}, {&(0x7f0000000a80)=""/110, 0x6e}, {&(0x7f0000000b00)=""/145, 0x91}, {&(0x7f0000000bc0)=""/108, 0x6c}, {&(0x7f0000000c40)=""/239, 0xef}, {&(0x7f0000000d40)=""/52, 0x34}], 0xa}, 0xffffffff}, {{&(0x7f0000000e40)=@in6={0xa, 0x0, 0x0, @mcast1}, 0x80, &(0x7f0000001400)=[{&(0x7f0000000ec0)=""/82, 0x52}, {&(0x7f0000000f40)=""/211, 0xd3}, {&(0x7f0000001040)=""/152, 0x98}, {&(0x7f0000001200)=""/241, 0xf1}, {&(0x7f0000001100)=""/6, 0x6}, {&(0x7f0000001300)=""/244, 0xf4}, {&(0x7f0000001140)=""/14, 0xe}, {&(0x7f0000001180)=""/54, 0x36}], 0x8, &(0x7f0000002b00)=""/4096, 0x1000}, 0xff}, {{0x0, 0x0, &(0x7f0000001840)=[{&(0x7f0000001480)=""/208, 0xd0}, {&(0x7f0000001580)=""/183, 0xb7}, {&(0x7f0000001640)=""/23, 0x17}, {&(0x7f0000001680)=""/216, 0xd8}, {&(0x7f0000001780)=""/185, 0xb9}], 0x5, &(0x7f00000018c0)=""/151, 0x97}, 0x81}, {{&(0x7f0000001980)=@pptp={0x18, 0x2, {0x0, @empty}}, 0x80, &(0x7f0000001a00)}, 0x3}, {{&(0x7f0000001a40)=@hci, 0x80, &(0x7f0000004200)=[{&(0x7f0000003b00)=""/98, 0x62}, {&(0x7f0000003b80)=""/136, 0x88}, {&(0x7f0000003c40)=""/123, 0x7b}, {&(0x7f0000003cc0)=""/167, 0xa7}, {&(0x7f0000003d80)=""/70, 0x46}, {&(0x7f0000003e00)=""/181, 0xb5}, {&(0x7f0000003ec0)=""/203, 0xcb}, {&(0x7f0000003fc0)=""/120, 0x78}, {&(0x7f0000004040)=""/182, 0xb6}, {&(0x7f0000004100)=""/247, 0xf7}], 0xa, &(0x7f00000042c0)=""/88, 0x58}, 0xffffff62}, {{&(0x7f0000004340)=@hci, 0x80, &(0x7f00000043c0), 0x0, &(0x7f0000004400)=""/10, 0xa}, 0x7}], 0x8, 0x120, 0x0)
shutdown(r0, 0x1)

23:05:50 executing program 1:
r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
bind$inet6(r0, &(0x7f0000000180)={0xa, 0x4e23, 0x0, @loopback}, 0x1c)
listen(r0, 0x0)
r1 = socket$inet6_mptcp(0xa, 0x1, 0x106)
setsockopt$sock_int(r0, 0x1, 0x8, &(0x7f0000000000), 0x4)
connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x4e23, 0x0, @loopback}, 0x63)
r2 = accept(r0, 0x0, 0x0)
syz_genetlink_get_family_id$mptcp(0x0, 0xffffffffffffffff)
sendmsg$nl_route_sched(r2, 0x0, 0x0)
r3 = socket(0x1, 0x5, 0x0)
connect$unix(r3, &(0x7f00000001c0)=@file={0x1, './file0\x00'}, 0x6e)
setsockopt$inet6_tcp_TCP_CONGESTION(r3, 0x6, 0xd, &(0x7f0000000040)='vegas\x00', 0x6)
r4 = dup(0xffffffffffffffff)
sendmmsg$inet6(r4, &(0x7f0000001380), 0x0, 0x0)
setsockopt$sock_int(r2, 0x1, 0x8, &(0x7f0000000240)=0x80000000, 0x4)
sendto$inet6(r1, &(0x7f0000000100)="3669464aaf98d5613027b6ace888b20c837d1f2310a070dc3538e1d1b0e8b92c59e129a89ea5cf46d9d9d9a38ce1060f716f16a5d7e430b46fc25d290aafd1c1d853ac727b8f9b318c24976ed3e5fb02b65501dc3f1ee57818462cb90f49ceee7165b73b690501cb26ef21c32373d7", 0xffffffffffffffbb, 0x0, 0x0, 0x0)
shutdown(r2, 0x1)

[  419.594615] ------------[ cut here ]------------
[  419.595237] WARNING: CPU: 0 PID: 10691 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc03/0xde0
[  419.595259] Modules linked in:
[  419.595268] CPU: 0 PID: 10691 Comm: kworker/0:9 Not tainted 6.6.0-rc2-g331b78eb12af #45
[  419.595276] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
[  419.595283] Workqueue: events mptcp_worker
[  419.595293] RIP: 0010:mptcp_sendmsg_frag+0xc03/0xde0
[  419.595302] Code: 63 23 dc fe 48 ff cb 48 89 dd e9 09 fa ff ff e8 53 23 dc fe 0f 0b e9 0d fb ff ff e8 47 23 dc fe e9 1e fc ff ff e8 3d 23 dc fe <0f> 0b e9 a7 f8 ff ff e8 31 23 dc fe e9 2f f8 ff ff f3 0f 1e fa 65
[  419.595309] RSP: 0000:ffffc900006fbbe0 EFLAGS: 00010293
[  419.595314] RAX: ffffffff8243ca03 RBX: b20668d30234ad5f RCX: ffff888101859e00
[  419.595319] RDX: 0000000000000000 RSI: b20668d30234ad5f RDI: b20668d30234ad5f
[  419.595324] RBP: b20668d30234ad5e R08: ffffffff8243c290 R09: ffffffff82042b3c
[  419.595329] R10: 0000000000000002 R11: ffffffff820564d0 R12: ffff888101e3b900
[  419.595336] R13: 0000000000001458 R14: ffff88812e9f8a90 R15: ffff88811a4f5400
[  419.595343] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
[  419.595355] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  419.595364] CR2: 0000001b33724000 CR3: 0000000102176005 CR4: 0000000000170ef0
[  419.595375] Call Trace:
[  419.595382]  <TASK>
[  419.595388]  ? __warn+0x10e/0x2d0
[  419.595430]  ? report_bug+0x2a3/0x3c0
[  419.595443]  ? mptcp_sendmsg_frag+0xc03/0xde0
[  419.595451]  ? handle_bug+0x3d/0x80
[  419.595460]  ? exc_invalid_op+0x1a/0x50
[  419.595468]  ? asm_exc_invalid_op+0x1a/0x20
[  419.595478]  ? __pfx_tcp_stream_memory_free+0x10/0x10
[  419.595488]  ? tcp_write_xmit+0x25c/0x1dd0
[  419.595499]  ? mptcp_sendmsg_frag+0x490/0xde0
[  419.595516]  ? mptcp_sendmsg_frag+0xc03/0xde0
[  419.595524]  ? mptcp_sendmsg_frag+0xc03/0xde0
[  419.595534]  __subflow_push_pending+0xa4/0x420
[  419.595542]  __mptcp_push_pending+0x128/0x3b0
[  419.595550]  mptcp_release_cb+0x218/0x5b0

@pabeni
Copy link

pabeni commented Oct 4, 2023

the triggered warning is:

               /* all mptcp-level data is acked, no skbs should be present into the
		 * ssk write queue
		 */
		WARN_ON_ONCE(reuse_skb);

Reviewing the code again, I think that in theory we could have a (reinjected?!?) packet in the subflow write queue and while receiving and msk level ack moving the snd_una up to snd_nxt. And that can happen while executing mptcp_sendmsg_frag(), if there are multiple established subflows, as snd_una is updated under the mptcp_data_lock.

The following patch should avoid the splat:

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 990fcf53074a..2b540b3681b8 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -1297,7 +1297,7 @@ static int mptcp_sendmsg_frag(struct sock *sk, struct sock *ssk,
        if (copy == 0) {
                u64 snd_una = READ_ONCE(msk->snd_una);
 
-               if (snd_una != msk->snd_nxt) {
+               if (snd_una != msk->snd_nxt || tcp_write_queue_tail(ssk)) {
                        tcp_remove_empty_skb(ssk);
                        return 0;
                }

@cpaasch: could you please give it a shot in your testbed?!?

Still I'm not sure if and why exactly the above described race could happen, so a possible, alternative, debug patch could be helpful:

@@ -1309,7 +1309,10 @@ static int mptcp_sendmsg_frag(struct sock *sk, struct sock *ssk,
                /* all mptcp-level data is acked, no skbs should be present into the
                 * ssk write queue
                 */
-               WARN_ON_ONCE(reuse_skb);
+               if (WARN_ON_ONCE(reuse_skb))
+                       pr_warn("acked bytes %lld sent bytes %lld snd_una %lld skb seq %lld skb len %d data seq %lld subflows %d",
+                               msk->bytes_acked, msk->bytes_sent, snd_una, mpext ? mpext->data_seq : -1,
+                               skb->len, dfrag->data_seq + info->sent, msk->pm.subflows);
        }
 
        copy = min_t(size_t, copy, info->limit - info->sent);

@cpaasch: it would be great if you could reproduce at least once the issue with the debug patch applied before testing the tentative fix, thanks!

cpaasch added a commit that referenced this issue Oct 4, 2023
@cpaasch
Copy link
Member Author

cpaasch commented Oct 4, 2023

Sure - updating with the debug patch now.

@cpaasch
Copy link
Member Author

cpaasch commented Oct 5, 2023

@pabeni :

netlink: 'syz-executor.1': attribute type 6 has an invalid length.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
Code: 40 1f dc fe 48 ff cb 48 89 dd e9 ce f9 ff ff e8 30 1f dc fe 0f 0b e9 13 fb ff ff e8 24 1f dc fe e9 24 fc ff ff 4c 89 6c 24 08 <0f> 0b 48 8b 44 24 30 4c 8b a8 98 05 00 00 48 8b 80 f0 05 00 00 48
RSP: 0018:ffffc90000a97bd0 EFLAGS: 00010202
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>
---[ end trace 0000000000000000 ]---
MPTCP: acked bytes 299671 sent bytes 299671 snd_una 5174727290961526635 skb seq 5174727290961526586 skb len 49 data seq 5174727290961526635 subflows 0
------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1344 mptcp_sendmsg_frag+0xbf0/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Tainted: G        W          6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xbf0/0xe70 net/mptcp/protocol.c:1344
Code: e9 ae fd ff ff e8 50 1f dc fe 48 ff cb 48 89 dd e9 81 f9 ff ff e8 40 1f dc fe 48 ff cb 48 89 dd e9 ce f9 ff ff e8 30 1f dc fe <0f> 0b e9 13 fb ff ff e8 24 1f dc fe e9 24 fc ff ff 4c 89 6c 24 08
RSP: 0018:ffffc90000a97bd0 EFLAGS: 00010293
RAX: ffffffff8243ce10 RBX: ffff88812a13d580 RCX: ffff8881015d3c00
RDX: 0000000000000000 RSI: 00000000fffffc0a RDI: 0000000000000001
RBP: 00000000fffffc0a R08: ffffffff8243c713 R09: ffffffff81134d19
R10: 0000000000000009 R11: ffff8881015d3c00 R12: 0000000000000001
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>
---[ end trace 0000000000000000 ]---

@cpaasch
Copy link
Member Author

cpaasch commented Oct 5, 2023

Adding the fix now..

cpaasch added a commit that referenced this issue Oct 5, 2023
@cpaasch
Copy link
Member Author

cpaasch commented Oct 9, 2023

@pabeni - the fix resolves the issue for me.

cpaasch added a commit that referenced this issue Oct 10, 2023
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this issue Oct 11, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a torvalds#47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warning.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
matttbe pushed a commit that referenced this issue Oct 13, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: #444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
matttbe pushed a commit that referenced this issue Oct 13, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: #444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
matttbe pushed a commit that referenced this issue Oct 16, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: #444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
matttbe pushed a commit that referenced this issue Oct 16, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: #444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
jenkins-tessares pushed a commit that referenced this issue Oct 17, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: #444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
jenkins-tessares pushed a commit that referenced this issue Oct 17, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: #444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this issue Oct 19, 2023
Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a torvalds#47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this issue Oct 22, 2023
commit 72377ab upstream.

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a torvalds#47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mj22226 pushed a commit to mj22226/linux that referenced this issue Oct 23, 2023
commit 72377ab upstream.

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a torvalds#47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kaz205 pushed a commit to Kaz205/linux that referenced this issue Oct 25, 2023
commit 72377ab upstream.

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a torvalds#47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DawnBreather pushed a commit to DawnBreather/linux-kernel that referenced this issue Oct 25, 2023
commit 72377ab upstream.

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DawnBreather pushed a commit to DawnBreather/linux-kernel that referenced this issue Oct 25, 2023
commit 72377ab upstream.

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Nov 8, 2023
[ Upstream commit 72377ab ]

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sparkstar pushed a commit to sparkstar/jammy-stable that referenced this issue Jan 18, 2024
BugLink: https://bugs.launchpad.net/bugs/2049417

[ Upstream commit 72377ab2d671befd6390a1d5677f5cca61235b65 ]

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1085d1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
sparkstar pushed a commit to sparkstar/jammy-stable that referenced this issue Jan 22, 2024
BugLink: https://bugs.launchpad.net/bugs/2049417

[ Upstream commit 72377ab2d671befd6390a1d5677f5cca61235b65 ]

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1085d1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
sileshn pushed a commit to sileshn/ubuntu-kernel-jammy that referenced this issue Feb 4, 2024
BugLink: https://bugs.launchpad.net/bugs/2049417

[ Upstream commit 72377ab2d671befd6390a1d5677f5cca61235b65 ]

Christoph reported that the MPTCP protocol can find the subflow-level
write queue unexpectedly not empty while crafting a zero-window probe,
hitting a warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 188 at net/mptcp/protocol.c:1312 mptcp_sendmsg_frag+0xc06/0xe70
Modules linked in:
CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 6.6.0-rc2-g1176aa719d7a #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:mptcp_sendmsg_frag+0xc06/0xe70 net/mptcp/protocol.c:1312
RAX: 47d0530de347ff6a RBX: 47d0530de347ff6b RCX: ffff8881015d3c00
RDX: ffff8881015d3c00 RSI: 47d0530de347ff6b RDI: 47d0530de347ff6b
RBP: 47d0530de347ff6b R08: ffffffff8243c6a8 R09: ffffffff82042d9c
R10: 0000000000000002 R11: ffffffff82056850 R12: ffff88812a13d580
R13: 0000000000000001 R14: ffff88812b375e50 R15: ffff88812bbf3200
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000695118 CR3: 0000000115dfc001 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 __subflow_push_pending+0xa4/0x420 net/mptcp/protocol.c:1545
 __mptcp_push_pending+0x128/0x3b0 net/mptcp/protocol.c:1614
 mptcp_release_cb+0x218/0x5b0 net/mptcp/protocol.c:3391
 release_sock+0xf6/0x100 net/core/sock.c:3521
 mptcp_worker+0x6e8/0x8f0 net/mptcp/protocol.c:2746
 process_scheduled_works+0x341/0x690 kernel/workqueue.c:2630
 worker_thread+0x3a7/0x610 kernel/workqueue.c:2784
 kthread+0x143/0x180 kernel/kthread.c:388
 ret_from_fork+0x4d/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:304
 </TASK>

The root cause of the issue is that expectations are wrong: e.g. due
to MPTCP-level re-injection we can hit the critical condition.

Explicitly avoid the zero-window probe when the subflow write queue
is not empty and drop the related warnings.

Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: multipath-tcp/mptcp_net-next#444
Fixes: f70cad1085d1 ("mptcp: stop relying on tcp_tx_skb_cache")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20231018-send-net-20231018-v1-3-17ecb002e41d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants