| Message ID | 7245da72fb7b1936b2c872c8a8c465012763ed17.1606385694.git.pabeni@redhat.com |
|---|---|
| State | Accepted, archived |
| Commit | 8e76b1043ebe8ef8018d4e8041320c7b62d9cbb9 |
| Delegated to: | Matthieu Baerts |
| Headers | show |
| Series | [net] mptcp: fix NULL ptr dereference on bad MPJ | expand |
Hi Paolo, On 26/11/2020 11:15, 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. Thanks for the fix! Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Just added in our tree: - 8e76b1043ebe: mptcp: fix NULL ptr dereference on bad MPJ - Results: a7a4732c5cdb..aad014029dd8 Tests + export are in progress! Cheers, Matt
On Thu, 2020-11-26 at 11:15 +0100, 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()") > Signed-off-by: Paolo Abeni <pabeni@redhat.com> kernel does not crash anymore. It still sends a 0 HMAC, and resets the connection after the 3WHS - see https://paste.centos.org/view/d962741c (not sure if it's RFC compliant, but for sure it fixes the issue :) ) Tested-by: Davide Caratti <dcaratti@redhat.com>
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; }
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()") Signed-off-by: Paolo Abeni <pabeni@redhat.com> --- net/mptcp/subflow.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)