-
-
Notifications
You must be signed in to change notification settings - Fork 51
Closed
Labels
bugreproducerHas a simple program to reproduce the bugHas a simple program to reproduce the bugsyzkaller
Description
This bug has been initially reported by syzbot here.
- HEAD commit: 78d4f34 Linux 6.13-rc3
- git tree: upstream
- console+strace: https://syzkaller.appspot.com/x/log.txt?x=16445730580000
- kernel config: https://syzkaller.appspot.com/x/.config?x=6c532525a32eb57d
- dashboard link: https://syzkaller.appspot.com/bug?extid=38a095a81f30d82884c1
- compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
- syz repro: https://syzkaller.appspot.com/x/repro.syz?x=169b0b44580000
- C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13f502df980000
- The bisected commit looks wrong.
According to Eric, there might be shinfo->nr_frags
corruptions. The repro seems to be using MPTCP, TFO, multiple subflows (triggered via the netlink API), and likely fallback to TCP racing with subflow creation.
Tip from Paolo:
If it's easy to reproduce, perhaps adding some debug patches will help catching when the corruption happens. Or perhaps it could help dumping as much subflow/msk state info as possible (sk the client? [I guess so] is sk the first subflow? how much data has been sent? is msk already in fallback status?) in tcp_clean_rtx_queue() when we detect a corrupted skb.
Metadata
Metadata
Assignees
Labels
bugreproducerHas a simple program to reproduce the bugHas a simple program to reproduce the bugsyzkaller