On Wed, 2 Dec 2020, Paolo Abeni wrote:
Eric noted the MPTCP recvmsg() loop can iterate multiple
times when the argument lenght is 0 and some subflow is
feeding new data.
Be sure to quite the loop soon moving the exit condition
earlier. Additionally move a related comment into the
Reported-by: Eric Dumazet <eric.dumazet(a)gmail.com>
Fixes: ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling")
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Note: looking again at the current code, I think that at worst we
can do a single additional, unneeded iteration - after the first
'continue' statement __mptcp_move_skbs() will have moved some data
into the receive_queue, and we are not going to receive them. On
next iteration the receive_queue will be not empty.
Unless the peer is crafting some malicious DSS/packets combo I'm
unable to foreseen.
net/mptcp/protocol.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
To close the loop here on the mailing list (based on IRC, patchwork, and
netdev), Paolo has tested Eric's fix for the issue and that will be