Received: by 10.213.65.68 with SMTP id h4csp1372243imn; Wed, 14 Mar 2018 19:22:28 -0700 (PDT) X-Google-Smtp-Source: AG47ELs93cUrQSOap3iWpLEN52a6lB2bpUyMDI3Z4vAN8Vi0AqPeDWcK1ihzqonn7IGMGZA8Q2wt X-Received: by 10.101.93.138 with SMTP id f10mr5435956pgt.255.1521080547924; Wed, 14 Mar 2018 19:22:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521080547; cv=none; d=google.com; s=arc-20160816; b=A7P2yyy2v+1GmSiWRL3cWB9HhwNYfULuqT5VWwtDOzPILArb7Lhihv9ptuDPYjz75N wKBd4oOflmgRl5X6OTRuXgjwB1e3uuHA+RedSksC2B+UEco1NpKK5qN5gFKj88Gce1gs sAEZ8a5YduLF4RVdNEbmCMsCWvmBq/28mrSz/uiyQBWYhUd/ys+ATDtL040ceUDBAGr6 ZwQC7iS6DWxqivdtfvtK3Cu1Q0ZpYORyIoccnR46Gbyhc5jz0EqBQv8jlBKaZxVglGIV hxgmKwzFh9RZFdTaJnaRPCwKtB5thuwyQGe9cno0h0dMnaGsgYLiW6pRZAQVUSsR05Dn pSiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=WF9GhqY4W9FduHQpGRK1dCrhzauUTMJnGfiYvkwadug=; b=MjzPt5AkVu8JB9ZEZmC6O8rlZa0bND3CHjcTwj3S0zatmKdrgsN3ZLmf2sx/ceZm8w cqvBi1SC8Q+qZ4/aVQ0gjUaivmNoKZsAz9RKXCu3KYq4UXin+sTNpAOebkCAOzGZaJrF ygrB382SgCnXRoRSIPfkrOpI05Igqb/nx3oUoc9qs01WdpwuvHKfHUydsnPnezXPDykd 9nBt3RABvCf5xyaRf1x8zCOsW84lppeA81FP0ltbT2qiMBbrwK4kixefc3oWUp9QEkS7 h368wHOfhsfhEOCdhXGBAO6vCzGSuzbyMIrCWTJ+1pekvxLIwpxenfdh30+wIge0QcnI 5eig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dt7fBHdA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f64si3083818pfa.115.2018.03.14.19.22.12; Wed, 14 Mar 2018 19:22:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dt7fBHdA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751682AbeCOCVT (ORCPT + 99 others); Wed, 14 Mar 2018 22:21:19 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:44091 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbeCOCVR (ORCPT ); Wed, 14 Mar 2018 22:21:17 -0400 Received: by mail-pl0-f68.google.com with SMTP id 9-v6so2852281ple.11; Wed, 14 Mar 2018 19:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WF9GhqY4W9FduHQpGRK1dCrhzauUTMJnGfiYvkwadug=; b=dt7fBHdAEZ6HHOzRXvabCR89viwyEVuYBY0htqUvze8QeWyvD7xxmuiRbmq4wg1CXp paNaCXaAwaH9V/KYVr3VnKkIggtRH1NFM955BF2SsJAXBsDERp8M2StDYCnhDdH4AwF/ ZMnSSVMxGS2qiRje6IHjrWltQYA8Py3jIVhqqofkX3qRqS7zabpIENa+SIJDUcSNmKDr 3AcAggyLGbx/9WyWJdWPpe/9ybIeNNUF6NHF0xQAb9F8ebYL5hV1n1UtgnnjZ9bBuvmD fR2rBPIGz9z8LM6e19zdF7unLTmLXlSAgXcMgq/JoDWuysTkMMhtCVFQ4Iqfd3XcWLo2 v+9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WF9GhqY4W9FduHQpGRK1dCrhzauUTMJnGfiYvkwadug=; b=m5Jxdywc/MNWOE3mfHbEWJlGeky22KBNbgVibKtmgC5LOssHcBBuNdwc0jj2j9PVqt 9pXonyzz8i2wXcD5LAxjxrutD69XQ+CEM7y0k/xL4UcojcOm62zsMDShMKNic2ivFiFo H3JsBOd7qZ3HjceYHGhdi93M3hPyGrGubE/FBPm7pvD9299+1e9m7KG/LyW/KtTpI1w6 iOKF7O0H1285Xq4OibPWCc0GYxWcnsHzIDh8nfT34mV4lDVSXBikA+wA1TULULEVz0Vl QTCBThCGoO5YaBAWI6Btqoz/y/5PYRa8Qll07iETycGSrqb+Oc7QqvKLOVfKehFPq/UM TwJQ== X-Gm-Message-State: AElRT7Hqj+r3RfTmE3oRMbklqJbHnyGCjEHM/j+B7gDYfJfec7vceyfE PwyAFcKP3o8M2sWFh8//tic= X-Received: by 2002:a17:902:b101:: with SMTP id q1-v6mr6193922plr.287.1521080476334; Wed, 14 Mar 2018 19:21:16 -0700 (PDT) Received: from zzz.localdomain (c-67-185-97-198.hsd1.wa.comcast.net. [67.185.97.198]) by smtp.gmail.com with ESMTPSA id z21sm6505262pge.42.2018.03.14.19.21.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Mar 2018 19:21:14 -0700 (PDT) Date: Wed, 14 Mar 2018 19:21:12 -0700 From: Eric Biggers To: Tycho Andersen Cc: David Howells , keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, James Morris , "Serge E. Hallyn" Subject: Re: [PATCH 2/2] dh key: get rid of stack array allocation Message-ID: <20180315022112.GB641@zzz.localdomain> References: <20180313042907.29598-1-tycho@tycho.ws> <20180313042907.29598-2-tycho@tycho.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180313042907.29598-2-tycho@tycho.ws> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 12, 2018 at 10:29:07PM -0600, Tycho Andersen wrote: > Similarly to the previous patch, we would like to get rid of stack > allocated arrays: https://lkml.org/lkml/2018/3/7/621 > > In this case, we can also use a malloc style approach to free the temporary > buffer, being careful to also use kzfree to free them (indeed, at least one > of these has a memzero_explicit, but it seems like maybe they both > should?). > > Signed-off-by: Tycho Andersen > CC: David Howells > CC: James Morris > CC: "Serge E. Hallyn" > --- > security/keys/dh.c | 27 +++++++++++++++++++++------ > 1 file changed, 21 insertions(+), 6 deletions(-) > > diff --git a/security/keys/dh.c b/security/keys/dh.c > index d1ea9f325f94..f02261b24759 100644 > --- a/security/keys/dh.c > +++ b/security/keys/dh.c > @@ -162,19 +162,27 @@ static int kdf_ctr(struct kdf_sdesc *sdesc, const u8 *src, unsigned int slen, > goto err; > > if (zlen && h) { > - u8 tmpbuffer[h]; > + u8 *tmpbuffer; > size_t chunk = min_t(size_t, zlen, h); > - memset(tmpbuffer, 0, chunk); > + > + err = -ENOMEM; > + tmpbuffer = kzalloc(chunk, GFP_KERNEL); > + if (!tmpbuffer) > + goto err; > > do { > err = crypto_shash_update(desc, tmpbuffer, > chunk); > - if (err) > + if (err) { > + kzfree(tmpbuffer); > goto err; > + } > > zlen -= chunk; > chunk = min_t(size_t, zlen, h); > } while (zlen); > + > + kzfree(tmpbuffer); > } This is just hashing zeroes. Why not use the zeroes at the end of the 'src' buffer which was allocated as 'outbuf' in __keyctl_dh_compute()? It's already the right size. It might even simplify the code a bit since crypto_shash_update() would no longer need to be in a loop. > > if (src && slen) { > @@ -184,13 +192,20 @@ static int kdf_ctr(struct kdf_sdesc *sdesc, const u8 *src, unsigned int slen, > } > > if (dlen < h) { > - u8 tmpbuffer[h]; > + u8 *tmpbuffer; > + > + err = -ENOMEM; > + tmpbuffer = kzalloc(h, GFP_KERNEL); > + if (!tmpbuffer) > + goto err; > > err = crypto_shash_final(desc, tmpbuffer); > - if (err) > + if (err) { > + kzfree(tmpbuffer); > goto err; > + } > memcpy(dst, tmpbuffer, dlen); > - memzero_explicit(tmpbuffer, h); > + kzfree(tmpbuffer); > return 0; > } else { > err = crypto_shash_final(desc, dst); > -- Why not instead round the allocated size of 'outbuf' in keyctl_dh_compute_kdf() up to the next 'crypto_shash_digestsize()'-boundary? Then this temporary buffer wouldn't be needed at all. It would be nice if people thought about how to properly solve the problems when doing these VLA conversions, rather than mindlessly replacing them with kmalloc... Eric