[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e245fb6a37d3c99df6efa934c5f05616bc1df7e7.camel@redhat.com>
Date: Fri, 27 Oct 2023 19:15:37 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: syzbot <syzbot+c53d4d3ddb327e80bc51@...kaller.appspotmail.com>,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
linux-kernel@...r.kernel.org, martineau@...nel.org,
matthieu.baerts@...sares.net, matttbe@...nel.org, mptcp@...ts.linux.dev,
netdev@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [mptcp?] WARNING in subflow_data_ready
On Wed, 2023-10-25 at 11:48 -0700, syzbot wrote:
> syzbot found the following issue on:
>
> HEAD commit: 9c5d00cb7b6b Merge tag 'perf-tools-fixes-for-v6.6-2-2023-1..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=123fbacd680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=530f7d8ed0a57417
> dashboard link: https://syzkaller.appspot.com/bug?extid=c53d4d3ddb327e80bc51
> compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
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.
/P
Powered by blists - more mailing lists