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: 10360929 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 2153360225 for ; Tue, 24 Apr 2018 20:28:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0EFD428A30 for ; Tue, 24 Apr 2018 20:28:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F3D2B28BDA; Tue, 24 Apr 2018 20:28:38 +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 DF45128A30 for ; Tue, 24 Apr 2018 20:28:37 +0000 (UTC) Received: (qmail 26276 invoked by uid 550); 24 Apr 2018 20:28:19 -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 26077 invoked from network); 24 Apr 2018 20:28:00 -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=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=qJlzHI9+CzUxsacN4kTnLJnqMZ210RTjp0DiOqETYEHpFWUgjesOUP1XdAbgkTW+il Bje+yK6d6wGjmg5JMcYoktREw1Jpomrb5F1EBNnugYzFIAz/czEHfwN/CEqighCl4+wu NfoleWHEM3yJV3yyznFRV6KBzjQPvVIQsVEDL2RoOk2ktl+N5UIpxqbK5LR0MSiKMRxr 3uNghMyBKUHj9ZfkxeJdYRd3RA3/0Wh9o10MBGUXcUnifCWXJwYrcJkE8Hud7SZ4SQJh 4V4bJvf2ahD96jbJmdaDRHhNsQ/dMSDz8xbISiCnocfvXJKEUpY0ZcFxaVvYiFvUa+vD AS6g== X-Gm-Message-State: ALQs6tDMenTKpwZlS1r9L5WHFbKM/4H6C3+iQ27Q8p1xKZP1YDmbsb8S 1oKt1cUTS9kYlDSt8gEgWUF0NA== 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) 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> 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); }