From patchwork Wed May 20 15:14:08 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tariq Toukan X-Patchwork-Id: 1294433 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=mellanox.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 49Rx9h0pJyz9sSF for ; Thu, 21 May 2020 01:14:16 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726833AbgETPOP (ORCPT ); Wed, 20 May 2020 11:14:15 -0400 Received: from mail-il-dmz.mellanox.com ([193.47.165.129]:60027 "EHLO mellanox.co.il" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726439AbgETPOO (ORCPT ); Wed, 20 May 2020 11:14:14 -0400 Received: from Internal Mail-Server by MTLPINE2 (envelope-from tariqt@mellanox.com) with ESMTPS (AES256-SHA encrypted); 20 May 2020 18:14:12 +0300 Received: from dev-l-vrt-206-005.mtl.labs.mlnx (dev-l-vrt-206-005.mtl.labs.mlnx [10.134.206.5]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id 04KFEC4o005725; Wed, 20 May 2020 18:14:12 +0300 From: Tariq Toukan To: "David S. Miller" Cc: netdev@vger.kernel.org, Jakub Kicinski , Boris Pismenny , Tariq Toukan , Saeed Mahameed Subject: [PATCH net] net/tls: Fix driver request resync Date: Wed, 20 May 2020 18:14:08 +0300 Message-Id: <20200520151408.8080-1-tariqt@mellanox.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Boris Pismenny In driver request resync, the hardware requests a resynchronization request at some TCP sequence number. If that TCP sequence number does not point to a TLS record header, then the resync attempt has failed. Failed resync should reset the resync request to avoid spurious resyncs after the TCP sequence number has wrapped around. Fix this by resetting the resync request when the TLS record header sequence number is not before the requested sequence number. As a result, drivers may be called with a sequence number that is not equal to the requested sequence number. Fixes: f953d33ba122 ("net/tls: add kernel-driven TLS RX resync") Signed-off-by: Boris Pismenny Signed-off-by: Tariq Toukan Reviewed-by: Saeed Mahameed --- net/tls/tls_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c index a562ebaaa33c..cbb13001b4a9 100644 --- a/net/tls/tls_device.c +++ b/net/tls/tls_device.c @@ -714,7 +714,7 @@ void tls_device_rx_resync_new_rec(struct sock *sk, u32 rcd_len, u32 seq) seq += TLS_HEADER_SIZE - 1; is_req_pending = resync_req; - if (likely(!is_req_pending) || req_seq != seq || + if (likely(!is_req_pending) || before(seq, req_seq) || !atomic64_try_cmpxchg(&rx_ctx->resync_req, &resync_req, 0)) return; break;