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: 10358457 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 EA88B601D2 for ; Tue, 24 Apr 2018 01:29:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DEB2228C9D for ; Tue, 24 Apr 2018 01:29:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CFC2028CC4; Tue, 24 Apr 2018 01:29:49 +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=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 6BACB28C9D for ; Tue, 24 Apr 2018 01:29:47 +0000 (UTC) Received: (qmail 6003 invoked by uid 550); 24 Apr 2018 01:29:46 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 5982 invoked from network); 24 Apr 2018 01:29:45 -0000 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=LCUuhUkTlUyHG8taNVPnQQoXzOEmEMLgl4CCx1f3TW6PxZCzXKD2WCX+nkib2xUv6F 8yLF7LjjR2cEA0NN76jGScFiJ9bheuv/Ss8X0ecOYJ2UaZxY0LkMWTpYvkW8PDVFq0NA mOcXVo59SY0UtdmE6fCrmVk0fEjzszgDxmwspL1Cai/4cZEyP7KKLTKoGwLpKMqOsIjo AjyVSEYyDGty7KbjtvQ/bHp9GtLrcew2zYq31XLFiiDW1QhoKA3wC+GmWyvOE0jzXrBn Fe4lPewNrEsTlylLlVCxVNHen5qQU1a36jCJE2EbxLktkQ3jONVp+vm+ubS33Q58B+Py fXzA== X-Gm-Message-State: ALQs6tAxzTzYzPmICgGLxDXVe0WrWPydlDvasYeR7DsYamzMT5wUMH1a xeIzgq9J3P1QsZqlKahfuqLMcg== 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) 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> 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); }