Re: [PATCH 5.10.y 1/3] mptcp: fix NULL pointer in can_accept_new_subflow

[Sasha Levin <sashal@kernel.org>]

[ Sasha's backport helper bot ]

Hi,

✅ All tests passed successfully. No issues detected.
No action required from the submitter.

The upstream commit SHA1 provided is correct: 443041deb5ef6a1289a99ed95015ec7442f141dc

WARNING: Author mismatch between patch and upstream commit:
Backport author: "Matthieu Baerts (NGI0)"<matttbe@kernel.org>
Commit author: Gang Yan<yangang@kylinos.cn>

Status in newer kernel trees:
6.14.y | Present (different SHA1: 4bf842c5219a)
6.13.y | Present (different SHA1: 17287762277c)
6.12.y | Present (different SHA1: 56a49eaa19a3)
6.6.y | Present (different SHA1: 1385117e486d)
6.1.y | Present (different SHA1: 820fc10033ea)
5.15.y | Present (different SHA1: 01cc5110710e)

Note: The patch differs from the upstream commit:
---
1:  443041deb5ef6 ! 1:  53310442b4043 mptcp: fix NULL pointer in can_accept_new_subflow
    @@ Metadata
      ## Commit message ##
         mptcp: fix NULL pointer in can_accept_new_subflow
     
    +    commit 443041deb5ef6a1289a99ed95015ec7442f141dc upstream.
    +
         When testing valkey benchmark tool with MPTCP, the kernel panics in
         'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL.
     
    @@ Commit message
         Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
         Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-1-34161a482a7f@kernel.org
         Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    +    [ Conflict in subflow.c because commit 74c7dfbee3e1 ("mptcp: consolidate
    +      in_opt sub-options fields in a bitmask") is not in this version. The
    +      conflict is in the context, and the modification can still be applied.
    +      Note that subflow_add_reset_reason() is not needed here, because the
    +      related feature is not supported in this version. ]
    +    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
     
      ## net/mptcp/subflow.c ##
     @@ net/mptcp/subflow.c: static bool subflow_hmac_valid(const struct request_sock *req,
    @@ net/mptcp/subflow.c: static bool subflow_hmac_valid(const struct request_sock *r
     -	if (!msk)
     -		return false;
      
    - 	subflow_generate_hmac(READ_ONCE(msk->remote_key),
    - 			      READ_ONCE(msk->local_key),
    + 	subflow_generate_hmac(msk->remote_key, msk->local_key,
    + 			      subflow_req->remote_nonce,
     @@ net/mptcp/subflow.c: static struct sock *subflow_syn_recv_sock(const struct sock *sk,
    - 
    + 			fallback = true;
      	} else if (subflow_req->mp_join) {
      		mptcp_get_options(skb, &mp_opt);
    --		if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK) ||
    --		    !subflow_hmac_valid(req, &mp_opt) ||
    +-		if (!mp_opt.mp_join || !subflow_hmac_valid(req, &mp_opt) ||
     -		    !mptcp_can_accept_new_subflow(subflow_req->msk)) {
     -			SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
    -+		if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK))
    ++		if (!mp_opt.mp_join)
      			fallback = true;
     -		}
      	}
      
      create_child:
     @@ net/mptcp/subflow.c: static struct sock *subflow_syn_recv_sock(const struct sock *sk,
    + 			if (!owner)
      				goto dispose_child;
    - 			}
      
     +			if (!subflow_hmac_valid(req, &mp_opt) ||
     +			    !mptcp_can_accept_new_subflow(subflow_req->msk)) {
     +				SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
    -+				subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT);
     +				goto dispose_child;
     +			}
     +
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-5.10.y       |  Success    |  Success   |