From patchwork Mon Mar 25 10:32:58 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Juerg Haefliger X-Patchwork-Id: 1915511 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=185.125.189.65; helo=lists.ubuntu.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=patchwork.ozlabs.org) Received: from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4V38Rp00bNz1yWy for ; Mon, 25 Mar 2024 21:33:57 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=lists.ubuntu.com) by lists.ubuntu.com with esmtp (Exim 4.86_2) (envelope-from ) id 1roheG-0000p6-ON; Mon, 25 Mar 2024 10:33:49 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1rohdf-0000LG-Lv for kernel-team@lists.ubuntu.com; Mon, 25 Mar 2024 10:33:12 +0000 Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id CBEE93F682 for ; Mon, 25 Mar 2024 10:33:09 +0000 (UTC) Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2d45c064742so47554781fa.3 for ; Mon, 25 Mar 2024 03:33:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711362789; x=1711967589; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sjkUgcMPsehoJSK23gXxu/HfkCMYTIN4uPSbCfHx0ys=; b=trjPtobBQrvmCBG8oLPQa/B/uHWYSaszs7n/61/yswYkOI330R+5r9z4bcAlHhbv1o ZOJvroiLrDBX7J/dK4/sDVZdbYF36AtoHYfEgfKcn4h+r9Q7FFwLcFgmKwtE26G9Hz2r 2I6WEU10LvuBXjBsqqwQAEBrdJ1KxaRPBew2e+348tV6PSdnCh3oSyfV1+5yztXxLyFJ gM7cLKHNDXy534kpfzNRDW98R4HJXduqHL6YElIJgLK8RgY6c5XdZXg6f4SM3AmIvNYg tB8JXpt4Nz6e/sBbyrFnbXkQuoES6YTMJFoOU0Cf2pDeVhWr/yOadRGWSoinCJyiM23I qQ/Q== X-Gm-Message-State: AOJu0YyKelU5IkVPuUktcb3rk62FutPTCAmCc+nncUIgczeesI04EvWJ A10tJH7DqV2dia5L2R5OYwlkEXFW6lGU3G+VzNDQT4tTBF3K3430k+c9AcDrhks/7Cww04IUBrB mKZpP3b43jW130ECa6RHWQRLY5GfZ5cEtiJ1uRQAHj2X+4+HA23SuvJ/Ppu8b0pqx2RFwgVLxMj 0UoyXDRiNqwQ== X-Received: by 2002:a2e:9ccd:0:b0:2d4:2651:1483 with SMTP id g13-20020a2e9ccd000000b002d426511483mr3886113ljj.35.1711362789235; Mon, 25 Mar 2024 03:33:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHPctozq1MYSvdurnkHWXDTC6jJjy1sx/nuYACJF6SgmIsJYe7O0wx9r9hkeeo5T8v8dBg5zg== X-Received: by 2002:a2e:9ccd:0:b0:2d4:2651:1483 with SMTP id g13-20020a2e9ccd000000b002d426511483mr3886104ljj.35.1711362788986; Mon, 25 Mar 2024 03:33:08 -0700 (PDT) Received: from localhost ([81.221.247.52]) by smtp.gmail.com with ESMTPSA id l21-20020a05600c4f1500b004148ab95c36sm1476020wmq.41.2024.03.25.03.33.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 03:33:08 -0700 (PDT) From: Juerg Haefliger To: kernel-team@lists.ubuntu.com Subject: [SRU][M][PATCH 6/8] net: tls: handle backlogging of crypto requests Date: Mon, 25 Mar 2024 11:32:58 +0100 Message-Id: <20240325103300.494141-7-juerg.haefliger@canonical.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20240325103300.494141-1-juerg.haefliger@canonical.com> References: <20240325103300.494141-1-juerg.haefliger@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Jakub Kicinski CVE-2024-26584 [ Upstream commit 8590541473188741055d27b955db0777569438e3 ] Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical. Fixes: a54667f6728c ("tls: Add support for encryption using async offload accelerator") Fixes: 94524d8fc965 ("net/tls: Add support for async decryption of tls records") Co-developed-by: Sabrina Dubroca Signed-off-by: Sabrina Dubroca Link: https://lore.kernel.org/netdev/9681d1febfec295449a62300938ed2ae66983f28.1694018970.git.sd@queasysnail.net/ Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (cherry picked from commit 13eca403876bbea3716e82cdfe6f1e6febb38754 linux-6.6.y) Signed-off-by: Juerg Haefliger --- net/tls/tls_sw.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 53f618e47907..ad7ed6c203a9 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -196,6 +196,17 @@ static void tls_decrypt_done(void *data, int err) struct sock *sk; int aead_size; + /* If requests get too backlogged crypto API returns -EBUSY and calls + * ->complete(-EINPROGRESS) immediately followed by ->complete(0) + * to make waiting for backlog to flush with crypto_wait_req() easier. + * First wait converts -EBUSY -> -EINPROGRESS, and the second one + * -EINPROGRESS -> 0. + * We have a single struct crypto_async_request per direction, this + * scheme doesn't help us, so just ignore the first ->complete(). + */ + if (err == -EINPROGRESS) + return; + aead_size = sizeof(*aead_req) + crypto_aead_reqsize(aead); aead_size = ALIGN(aead_size, __alignof__(*dctx)); dctx = (void *)((u8 *)aead_req + aead_size); @@ -269,6 +280,10 @@ static int tls_do_decryption(struct sock *sk, } ret = crypto_aead_decrypt(aead_req); + if (ret == -EBUSY) { + ret = tls_decrypt_async_wait(ctx); + ret = ret ?: -EINPROGRESS; + } if (ret == -EINPROGRESS) { if (darg->async) return 0; @@ -449,6 +464,9 @@ static void tls_encrypt_done(void *data, int err) struct sk_msg *msg_en; struct sock *sk; + if (err == -EINPROGRESS) /* see the comment in tls_decrypt_done() */ + return; + msg_en = &rec->msg_encrypted; sk = rec->sk; @@ -553,6 +571,10 @@ static int tls_do_encryption(struct sock *sk, atomic_inc(&ctx->encrypt_pending); rc = crypto_aead_encrypt(aead_req); + if (rc == -EBUSY) { + rc = tls_encrypt_async_wait(ctx); + rc = rc ?: -EINPROGRESS; + } if (!rc || rc != -EINPROGRESS) { atomic_dec(&ctx->encrypt_pending); sge->offset -= prot->prepend_size;