Re: [PATCH mptcp-net v3] mptcp: fix divide-by-zero in __mptcp_push_pending close path

Paolo Abeni <[email protected]> Wed, 22 Jul 2026 10:53:50 +0200
Newsgroups dev.linux.lists.mptcp
Message-ID <[email protected]>
On 6/12/26 8:33 PM, Shardul Bankar wrote:
> Gentle ping on v3. It refines the v2 check that tripped the
> regressions, scoping it to just the divide-by-zero close-path case. CI
> on v3 was green except for a single Unstable flag (packetdrill_dss on
> the debug config) a flaky test unrelated to this change (it passed on
> normal).
> 
> Does v3 look acceptable as-is, or is there anything else you'd like
> adjusted?

I'm sorry for the latency. netdev PW backlog is killing me.

I fear this patch may introduce another race: if a ssk with
!__tcp_can_send() status reaches mptcp_sendmsg_frag(), `mss_now` could
be zero and we can hit a divide by zero in tcp_xmit_size_goal(). I think
syzkaller hit such race in the past.

Re-reading the patch changelog it's not clear to me the exact timing of
the race this patch should address: if __mptcp_close_ssk() leaves ssk in
a !__tcp_can_send() status, mptcp_subflow_get_send() should not pick
such subflow for transmission, as the latter explicitly gates subflow
selection with the same condition[1].

Is the repro using a BPF scheduler? Can you describe exactly the
sequence of events leading to the error? The decoded call trace will
help, but will not suffice in case of another process racing on the
relevant ssk - I think it's the latter case, due to [1].

I still think that refining the approach in v2 would be better. Did you
trace why self-tests were failing? I can't find a reply in that old thread.

Thanks,

Paolo