In subflow_finish_connect(), HMAC validation of the server's HMAC
in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was
wrong on ACK + MP_JOIN") on failure. The function processes the
SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter
("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not
incremented anywhere in the tree.

The mirror site on the server, subflow_syn_recv_sock(), already
uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC
at the SYN/ACK validation site so each counter reflects the packet
whose HMAC actually failed.

Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Fixes: 3eccc998b50b ("mptcp: increment MIB counters in a few places")
Cc: stable@vger.kernel.org
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
 net/mptcp/subflow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index e2cb9d23e4a0..bda6862264ca 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -581,7 +581,7 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
 			 subflow->backup);
 
 		if (!subflow_thmac_valid(subflow)) {
-			MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINACKMAC);
+			MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINSYNACKMAC);
 			subflow->reset_reason = MPTCP_RST_EMPTCP;
 			goto do_reset;
 		}
-- 
2.34.1

Hi Shardul,

On 28/04/2026 09:48, Shardul Bankar wrote:
> In subflow_finish_connect(), HMAC validation of the server's HMAC
> in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was
> wrong on ACK + MP_JOIN") on failure. The function processes the
> SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter
> ("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not
> incremented anywhere in the tree.
> 
> The mirror site on the server, subflow_syn_recv_sock(), already
> uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC
> at the SYN/ACK validation site so each counter reflects the packet
> whose HMAC actually failed.

Now in our tree (fixes for -net):

New patches for t/upstream-net and t/upstream:
- aec458ef6eb7: mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure
- Results: 581441b9adeb..4d36cf47658c (export-net)
- Results: d1636d717db9..83e40a2e5ca0 (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/35ef198760c9a2bea1ce2edb5f5d503bef518644/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/8a8f6fca4cf7c8d0b2f1f949e481a3d6840f3286/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Hi Shardul,

On 28/04/2026 09:48, Shardul Bankar wrote:
> In subflow_finish_connect(), HMAC validation of the server's HMAC
> in SYN/ACK + MP_JOIN increments MPTCP_MIB_JOINACKMAC ("HMAC was
> wrong on ACK + MP_JOIN") on failure. The function processes the
> SYN/ACK, not the ACK; the matching MPTCP_MIB_JOINSYNACKMAC counter
> ("HMAC was wrong on SYN/ACK + MP_JOIN") exists but is not
> incremented anywhere in the tree.
> 
> The mirror site on the server, subflow_syn_recv_sock(), already
> uses JOINACKMAC correctly for ACK HMAC failure. Use JOINSYNACKMAC
> at the SYN/ACK validation site so each counter reflects the packet
> whose HMAC actually failed.
> 
> Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> Fixes: 3eccc998b50b ("mptcp: increment MIB counters in a few places")

Thank you for this patch! It looks good to me, except this Fixes tag:
how did you get it? It is only available from an old archived branch:

  archived/t/upstream_20200401

Note that AI Coding Assistants are allowed, but the Assisted-by mention
is then required, see:

  https://docs.kernel.org/process/coding-assistants.html

Git blame should be done from the net/net-next branches or the
export/export-net ones.

I'm going to use this one instead:

Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure")

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Hi Shardul,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/25041571236

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/f83294fe083e
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1086634


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)