From patchwork Tue Apr 24 20:26:39 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tycho Andersen X-Patchwork-Id: 10360923 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 A76F7601BE for ; Tue, 24 Apr 2018 20:28:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 968BA28A30 for ; Tue, 24 Apr 2018 20:28:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8AF4D28BDA; Tue, 24 Apr 2018 20:28:20 +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 0B39D28A30 for ; Tue, 24 Apr 2018 20:28:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751226AbeDXU16 (ORCPT ); Tue, 24 Apr 2018 16:27:58 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:46108 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbeDXU1t (ORCPT ); Tue, 24 Apr 2018 16:27:49 -0400 Received: by mail-pf0-f196.google.com with SMTP id h69so13218223pfe.13 for ; Tue, 24 Apr 2018 13:27:49 -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=zVwg/XtOp7qOT82C31VjLPjQE83Md8m19QwRBi3Aiho=; b=qYqWEPrv+Qxz/4FicZR9H9ZZwC+SZvhDCXznV2ZP8l+JF/Fehx1kscQSNSh3iMrgI3 zjXpf5g7X+FZ/hCghJP2seL6Qlx9DYQqx+VMq/IMtX/l94LJH7weSf9fyippgRQJGqqK dM2KN8GDnxWhUe3DXeAnCkoiJMVVAHvTuDLo+yeX8kYMgPqDFhMMKRh9YLg09wOn/VhY ab/pNOZtq+3IU0yLcwWs4nxjk0srur/egM3O/1S1VNabLi5zEIgIfhbzifmIpygE4LLT 847xsBzcYOPmohIUrhh7Zigf8y5BoWcVDYsjhay3hampbObQBimKOGt7ZNLzcdiQ9bVQ bHmA== 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=zVwg/XtOp7qOT82C31VjLPjQE83Md8m19QwRBi3Aiho=; b=HUq6Y7oP9waYKwQgqWc/sxcmde6NMD2hQm3pGI0N1qy3pYWCWCxmxVx9aoxN1P8zO6 jwb5/TfI24oETqQ88Ysfl7NJERvdtsIh8k1uoDqlMTV4GfVKQTQmvNk0rEl99vxtpD9J bqzlvMcSLdpYhRxNU1gtyyoK+nP5OtlJPFz+AK6qicQGFYdq517YXX+OAZOEYUtdVcUw ZfjYu+M2xSm6/DelCTGAGcqnxawYNIsv/H/K9BTjP5awT+3cr/KC4ayfqnHGLo/g442i p0dIbaNUNrYqopiFj+zORkYbra/EohiTrWYWU+8kfYx2ziutAEcUrGbFjKrvcXHgU7zp Mdow== X-Gm-Message-State: ALQs6tB+DrQ1Eei856iyE0sVIiayJIkL8ZcNJsnvQJyEerE/MAcyojwj O8BPp8RfRHQj2uaBjGtjmSriFQ== X-Google-Smtp-Source: AIpwx48NT/4JtwOXX6DOg0fDj1XVqU2EreULUk2ZlPXpwYVEi0wfrdKh82gZM7+nrur/FY/YH6rZZg== X-Received: by 10.99.124.1 with SMTP id x1mr20787938pgc.286.1524601668945; Tue, 24 Apr 2018 13:27:48 -0700 (PDT) Received: from localhost.localdomain ([128.107.241.171]) by smtp.gmail.com with ESMTPSA id r82sm49943847pfk.187.2018.04.24.13.27.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Apr 2018 13:27:48 -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 v3 3/3] dh key: get rid of stack allocated array for zeroes Date: Tue, 24 Apr 2018 14:26:39 -0600 Message-Id: <20180424202639.19830-3-tycho@tycho.ws> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180424202639.19830-1-tycho@tycho.ws> References: <20180424202639.19830-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 32, since that is a common size, is not too 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 v3: fix typo of 256 -> 32 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..f7403821db7f 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[32]; + 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); }