From patchwork Tue Apr 24 01:03:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tycho Andersen X-Patchwork-Id: 10358451 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A41D6601D2 for ; Tue, 24 Apr 2018 01:04:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 98F1428B7F for ; Tue, 24 Apr 2018 01:04:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8C06D28CB3; Tue, 24 Apr 2018 01:04:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0905D28B7F for ; Tue, 24 Apr 2018 01:04:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932759AbeDXBDt (ORCPT ); Mon, 23 Apr 2018 21:03:49 -0400 Received: from mail-ot0-f196.google.com ([74.125.82.196]:45159 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932725AbeDXBDg (ORCPT ); Mon, 23 Apr 2018 21:03:36 -0400 Received: by mail-ot0-f196.google.com with SMTP id w4-v6so19377068ote.12 for ; Mon, 23 Apr 2018 18:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho-ws.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=PopBxbGfzaql5PthbzfuQy9JDtfE3NU4JPCNXim3sd4=; b=grndnHWaqpdCqVoiT3E9FlYwUrw695Mx5oXrkHxT6A4WAkQ86Hx+6WSMxQJOx3LEEP afPbRxWSKYWxeonpDnun07KcA64woZ0h7OdpyhISWER8XpJNdRZ6fPHwO4geXKaSjaT3 rqvXxL1SLe7eOmMYWurX6QZpWjWgW2LH+iMBVD2AbJM21oU2JwNNBQWl3dWGl31Fnk+U +Nw8hYgAcIBEy0X7lU8FP/FRXmlGhZPxA0ZJvlpeqiJdTpsQQVgPPmbX5Nvf+4eCdW8l MsNP5vd9tUHtE4BR7DEN6yZF0cGnAg4c4gGN/fUB9TZ70ZHUWYJfFjkbJSSkdDuWyUkt Ue9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=PopBxbGfzaql5PthbzfuQy9JDtfE3NU4JPCNXim3sd4=; b=Xj+I0ZV0Gj1nUgzF5KYdZIGq2uSvlwGvEJr9R8WoID+u0jlgM487Ppl316y4O37d++ Cyejg7nmshx8I2Wtj1tXV6A/DWlW1zxy7xdFXsybKMUouZud+ksoT4OUSRKQl5od+rCL byhucT/9zre0tdKg4DI/ZahjbW9beamGCxe4OR/Kq9j1KX56kBJGZvMyI+HRV4sDKwqP q1l/nEJ8FqHjAM0dFGiKFDV8E7dQbO2JllLxe8cWz3FWiTZ3mLFcnnWEt16YBc4rYt3+ WchUfuNSpnTJcCPJEzakRUOa/LIA0Vnl5gZ536hJ3PHyQoY7KumSs6dfjvSqJKb955Xl tUig== X-Gm-Message-State: ALQs6tAbtf5WXy7DzYS4jfOntGtxMot4Iem/N+jdfJdRSyXfpnwSImac fzRkCj9Luscnq1bRVIFrO+1p158c X-Google-Smtp-Source: AIpwx48isSQ63O1eIck058FQg1zsegTgg3iyWgxJFchJVyqrfyZxGvA4lyQ5GfpXfXwcXT2Ki3pnug== X-Received: by 2002:a9d:400d:: with SMTP id m13-v6mr16021310ote.391.1524531816240; Mon, 23 Apr 2018 18:03:36 -0700 (PDT) Received: from cisco.lan ([8.24.24.129]) by smtp.gmail.com with ESMTPSA id n204-v6sm7410331oia.3.2018.04.23.18.03.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 18:03:35 -0700 (PDT) From: Tycho Andersen To: David Howells Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Tycho Andersen , James Morris , "Serge E. Hallyn" , Eric Biggers Subject: [PATCH 3/3] dh key: get rid of stack allocated array for zeroes Date: Mon, 23 Apr 2018 19:03:21 -0600 Message-Id: <20180424010321.14739-3-tycho@tycho.ws> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180424010321.14739-1-tycho@tycho.ws> References: <20180424010321.14739-1-tycho@tycho.ws> Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP We're interested in getting rid of all of the stack allocated arrays in the kernel: https://lkml.org/lkml/2018/3/7/621 This case is interesting, since we really just need an array of bytes that are zero. The loop already ensures that if the array isn't exactly the right size that enough zero bytes will be copied in. So, instead of choosing this value to be the size of the hash, let's just choose it to be 256, since that is a common size, is not to big, and will not result in too many extra iterations of the loop. v2: split out from other patch, just hardcode array size instead of dynamically allocating something the right size Signed-off-by: Tycho Andersen CC: David Howells CC: James Morris CC: "Serge E. Hallyn" CC: Eric Biggers --- security/keys/dh.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/security/keys/dh.c b/security/keys/dh.c index 9fecaea6c298..74f8a853872e 100644 --- a/security/keys/dh.c +++ b/security/keys/dh.c @@ -162,8 +162,8 @@ static int kdf_ctr(struct kdf_sdesc *sdesc, const u8 *src, unsigned int slen, goto err; if (zlen && h) { - u8 tmpbuffer[h]; - size_t chunk = min_t(size_t, zlen, h); + u8 tmpbuffer[256]; + size_t chunk = min_t(size_t, zlen, sizeof(tmpbuffer)); memset(tmpbuffer, 0, chunk); do { @@ -173,7 +173,7 @@ static int kdf_ctr(struct kdf_sdesc *sdesc, const u8 *src, unsigned int slen, goto err; zlen -= chunk; - chunk = min_t(size_t, zlen, h); + chunk = min_t(size_t, zlen, sizeof(tmpbuffer)); } while (zlen); }