Message ID | 20250407-net-mptcp-hmac-failure-mib-v1-1-3c9ecd0a3a50@kernel.org |
---|---|
State | New |
Headers | show |
Series | mptcp: only inc MPJoinAckHMacFailure for HMAC failures | expand |
On Mon, Apr 07, 2025 at 08:26:32PM +0200, Matthieu Baerts (NGI0) wrote: > Recently, during a debugging session using local MPTCP connections, I > noticed MPJoinAckHMacFailure was not zero on the server side. The > counter was in fact incremented when the PM rejected new subflows, > because the 'subflow' limit was reached. > > The fix is easy, simply dissociating the two cases: only the HMAC > validation check should increase MPTCP_MIB_JOINACKMAC counter. > > Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()") > Cc: stable@vger.kernel.org > Reviewed-by: Geliang Tang <geliang@kernel.org> > Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org>
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 409bd415ef1d190d5599658d01323ad8c8a9be93..24c2de1891bdf31dfe04ef2077113563aad0e666 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -899,13 +899,17 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk, goto dispose_child; } - if (!subflow_hmac_valid(req, &mp_opt) || - !mptcp_can_accept_new_subflow(subflow_req->msk)) { + if (!subflow_hmac_valid(req, &mp_opt)) { SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); goto dispose_child; } + if (!mptcp_can_accept_new_subflow(owner)) { + subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); + goto dispose_child; + } + /* move the msk reference ownership to the subflow */ subflow_req->msk = NULL; ctx->conn = (struct sock *)owner;