From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5541C10F16 for ; Tue, 26 Feb 2019 12:13:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 828592173C for ; Tue, 26 Feb 2019 12:13:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726799AbfBZMNA (ORCPT ); Tue, 26 Feb 2019 07:13:00 -0500 Received: from mail-il-dmz.mellanox.com ([193.47.165.129]:58883 "EHLO mellanox.co.il" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725935AbfBZMM7 (ORCPT ); Tue, 26 Feb 2019 07:12:59 -0500 Received: from Internal Mail-Server by MTLPINE1 (envelope-from borisp@mellanox.com) with ESMTPS (AES256-SHA encrypted); 26 Feb 2019 14:12:53 +0200 Received: from gen-l-vrt-098.mtl.labs.mlnx (gen-l-vrt-098.mtl.labs.mlnx [10.137.170.1]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id x1QCCrKQ030499; Tue, 26 Feb 2019 14:12:53 +0200 From: Boris Pismenny To: aviadye@mellanox.com, davejwatson@fb.com, john.fastabend@gmail.com, daniel@iogearbox.net, vakul.garg@nxp.com, netdev@vger.kernel.org Cc: eranbe@mellanox.com, borisp@mellanox.com Subject: [PATCH net 3/4] tls: Fix mixing between async capable and async Date: Tue, 26 Feb 2019 14:12:34 +0200 Message-Id: <20190226121235.20784-4-borisp@mellanox.com> X-Mailer: git-send-email 2.12.2 In-Reply-To: <20190226121235.20784-1-borisp@mellanox.com> References: <20190226121235.20784-1-borisp@mellanox.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Eran Ben Elisha Today, tls_sw_recvmsg is capable of using asynchronous mode to handle application data TLS records. Moreover, it assumes that if the cipher can be handled asynchronously, then all packets will be processed asynchronously. However, this assumption is not always true. Specifically, for AES-GCM in TLS1.2, it causes data corruption, and breaks user applications. This patch fixes this problem by separating the async capability from the decryption operation result. Fixes: c0ab4732d4c6 ("net/tls: Do not use async crypto for non-data records") Signed-off-by: Eran Ben Elisha Reviewed-by: Boris Pismenny --- net/tls/tls_sw.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 4afa67b00aaf..f515cd7e984e 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -1693,7 +1693,8 @@ int tls_sw_recvmsg(struct sock *sk, bool zc = false; int to_decrypt; int chunk = 0; - bool async; + bool async_capable; + bool async = false; skb = tls_wait_data(sk, psock, flags, timeo, &err); if (!skb) { @@ -1727,21 +1728,23 @@ int tls_sw_recvmsg(struct sock *sk, /* Do not use async mode if record is non-data */ if (ctx->control == TLS_RECORD_TYPE_DATA) - async = ctx->async_capable; + async_capable = ctx->async_capable; else - async = false; + async_capable = false; err = decrypt_skb_update(sk, skb, &msg->msg_iter, - &chunk, &zc, async); + &chunk, &zc, async_capable); if (err < 0 && err != -EINPROGRESS) { tls_err_abort(sk, EBADMSG); goto recv_end; } - if (err == -EINPROGRESS) + if (err == -EINPROGRESS && async_capable) { + async = true; num_async++; - else if (prot->version == TLS_1_3_VERSION) + } else if (prot->version == TLS_1_3_VERSION) { tlm->control = ctx->control; + } /* If the type of records being processed is not known yet, * set it to record type just dequeued. If it is already known, -- 2.12.2