Message ID | 03b2cfa3ac80d8fc18272edc6442a9ddf0b1e34e.1606400227.git.pabeni@redhat.com (mailing list archive) |
---|---|
State | Accepted |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [net] mptcp: fix NULL ptr dereference on bad MPJ | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Clearly marked for net |
netdev/subject_prefix | success | Link |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 1 this patch: 1 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 11 lines checked |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 1 this patch: 1 |
netdev/header_inline | success | Link |
netdev/stable | success | Stable not CCed |
Hi Paolo, On 26/11/2020 15:17, Paolo Abeni wrote: > If an msk listener receives an MPJ carrying an invalid token, it > will zero the request socket msk entry. That should later > cause fallback and subflow reset - as per RFC - at > subflow_syn_recv_sock() time due to failing hmac validation. > > Since commit 4cf8b7e48a09 ("subflow: introduce and use > mptcp_can_accept_new_subflow()"), we unconditionally dereference > - in mptcp_can_accept_new_subflow - the subflow request msk > before performing hmac validation. In the above scenario we > hit a NULL ptr dereference. > > Address the issue doing the hmac validation earlier. > > Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()") > Tested-by: Davide Caratti <dcaratti@redhat.com> > Signed-off-by: Paolo Abeni <pabeni@redhat.com> Good catch! Thank you for the patch! Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Cheers, Matt
On Thu, 26 Nov 2020 16:23:08 +0100 Matthieu Baerts wrote: > On 26/11/2020 15:17, Paolo Abeni wrote: > > If an msk listener receives an MPJ carrying an invalid token, it > > will zero the request socket msk entry. That should later > > cause fallback and subflow reset - as per RFC - at > > subflow_syn_recv_sock() time due to failing hmac validation. > > > > Since commit 4cf8b7e48a09 ("subflow: introduce and use > > mptcp_can_accept_new_subflow()"), we unconditionally dereference > > - in mptcp_can_accept_new_subflow - the subflow request msk > > before performing hmac validation. In the above scenario we > > hit a NULL ptr dereference. > > > > Address the issue doing the hmac validation earlier. > > > > Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()") > > Tested-by: Davide Caratti <dcaratti@redhat.com> > > Signed-off-by: Paolo Abeni <pabeni@redhat.com> > > Good catch! Thank you for the patch! > > Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Applied, thanks!
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index ac4a1fe3550b..953906e40742 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -543,9 +543,8 @@ 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.mp_join || - !mptcp_can_accept_new_subflow(subflow_req->msk) || - !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); fallback = true; }