syzkaller: `WARNING` in `subflow_data_ready`

Reported by Google's syzbot:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 10630 at net/mptcp/subflow.c:1405 subflow_data_ready+0x39f/0x690 net/mptcp/subflow.c:1405
Modules linked in:
CPU: 0 PID: 10630 Comm: kworker/u4:11 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
Workqueue: bat_events batadv_nc_worker
RIP: 0010:subflow_data_ready+0x39f/0x690 net/mptcp/subflow.c:1405
Code: 18 89 ee e8 e3 d2 21 f7 40 84 ed 75 1f e8 a9 d7 21 f7 44 89 fe bf 07 00 00 00 e8 0c d3 21 f7 41 83 ff 07 74 07 e8 91 d7 21 f7 <0f> 0b e8 8a d7 21 f7 48 89 df e8 d2 b2 ff ff 31 ff 89 c5 89 c6 e8
RSP: 0018:ffffc90000007448 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff888031efc700 RCX: ffffffff8a65baf4
RDX: ffff888043222140 RSI: ffffffff8a65baff RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007
R10: 000000000000000b R11: 0000000000000000 R12: 1ffff92000000e89
R13: ffff88807a534d80 R14: ffff888021c11a00 R15: 000000000000000b
FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa19a0ffc81 CR3: 000000007a2db000 CR4: 00000000003506f0
DR0: 000000000000d8dd DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
 <IRQ>
 tcp_data_ready+0x14c/0x5b0 net/ipv4/tcp_input.c:5128
 tcp_data_queue+0x19c3/0x5190 net/ipv4/tcp_input.c:5208
 tcp_rcv_state_process+0x11ef/0x4e10 net/ipv4/tcp_input.c:6844
 tcp_v4_do_rcv+0x369/0xa10 net/ipv4/tcp_ipv4.c:1929
 tcp_v4_rcv+0x3888/0x3b30 net/ipv4/tcp_ipv4.c:2329
 ip_protocol_deliver_rcu+0x9f/0x480 net/ipv4/ip_input.c:205
 ip_local_deliver_finish+0x2e4/0x510 net/ipv4/ip_input.c:233
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netfilter.h:308 [inline]
 ip_local_deliver+0x1b6/0x550 net/ipv4/ip_input.c:254
 dst_input include/net/dst.h:461 [inline]
 ip_rcv_finish+0x1c4/0x2e0 net/ipv4/ip_input.c:449
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netfilter.h:308 [inline]
 ip_rcv+0xce/0x440 net/ipv4/ip_input.c:569
 __netif_receive_skb_one_core+0x115/0x180 net/core/dev.c:5527
 __netif_receive_skb+0x1f/0x1b0 net/core/dev.c:5641
 process_backlog+0x101/0x6b0 net/core/dev.c:5969
 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6531
 napi_poll net/core/dev.c:6600 [inline]
 net_rx_action+0x956/0xe90 net/core/dev.c:6733
 __do_softirq+0x21a/0x968 kernel/softirq.c:553
 do_softirq kernel/softirq.c:454 [inline]
 do_softirq+0xaa/0xe0 kernel/softirq.c:441
 </IRQ>
 <TASK>
 __local_bh_enable_ip+0xf8/0x120 kernel/softirq.c:381
 spin_unlock_bh include/linux/spinlock.h:396 [inline]
 batadv_nc_purge_paths+0x1ce/0x3c0 net/batman-adv/network-coding.c:471
 batadv_nc_worker+0x9b1/0x10e0 net/batman-adv/network-coding.c:722
 process_one_work+0x884/0x15c0 kernel/workqueue.c:2630
 process_scheduled_works kernel/workqueue.c:2703 [inline]
 worker_thread+0x8b9/0x1290 kernel/workqueue.c:2784
 kthread+0x33c/0x440 kernel/kthread.c:388
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
 </TASK>

First seen on 2023/10/21 18:38.

From Paolo:

FTR: preemptible kernel, last mptcp program run on the CPU splatting is:

r0 = socket$inet_mptcp(0x2, 0x1, 0x106)
bind$inet(r0, &(0x7f0000000040)={0x2, 0x4e24, @multicast2}, 0x10)
sendmmsg$inet(r0, &(0x7f0000000440)=[{{&(0x7f00000000c0)={0x2, 0x4e24, @empty}, 0x10, 0x0}}], 0x1, 0x24040890)
r1 = socket$nl_generic(0x10, 0x3, 0x10)
r2 = syz_genetlink_get_family_id$mptcp(&(0x7f0000000080), 0xffffffffffffffff)
setsockopt$inet_tcp_buf(r0, 0x6, 0xd, &(0x7f0000000140)="a7", 0x1)
sendmsg$MPTCP_PM_CMD_ADD_ADDR(r1, &(0x7f0000000300)={0x0, 0x0, &(0x7f0000000100)={&(0x7f0000000000)={0x28, r2, 0x1, 0x0, 0x0, {0x2}, [@MPTCP_PM_ATTR_ADDR={0x14, 0x1, 0x0, 0x1, [@MPTCP_PM_ADDR_ATTR_ADDR4={0x8, 0x3, @multicast2=0x7f000001}, @MPTCP_PM_ADDR_ATTR_FAMILY={0x6, 0x1, 0x2}]}]}, 0x28}, 0x1, 0xf00000000000000}, 0x0)

self-connecting fast-open with an empty data buffer (on a preemptible kernel, what could possibly go wrong?!? :-P)

The splat is caused by the following check:

  WARN_ON_ONCE(!__mptcp_check_fallback(msk) && !subflow->mp_capable &&
                     !subflow->mp_join && !(state & TCPF_CLOSE));

Without a repro it's hard to guess what is going on, but looks a valid mptcp related issue.

multipath-tcp / mptcp_net-next

syzkaller: `WARNING` in `subflow_data_ready` #458