You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
This bug has been initially reported by syzbot here.
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:
The text was updated successfully, but these errors were encountered: