Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3173271imm; Mon, 16 Jul 2018 23:39:50 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd9OdutZUeMJqyywUSxYrYMUS9oQoPCnEHmd/kqWiG2EBrzJTyJ/n6+RMbGBrVLlxqMi8vg X-Received: by 2002:a63:338e:: with SMTP id z136-v6mr340115pgz.171.1531809590804; Mon, 16 Jul 2018 23:39:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531809590; cv=none; d=google.com; s=arc-20160816; b=HgMtY58xzR6AXTYgf6ZAqv5Ab86wpG824W+xhyPsGlG1lO2OU7tfDZWkWeLE/0dRtb GwvhcRff/YPBhG1SEhygVMuDyoFRvSIdlpqFIhFpcj0V9OR7hRNXUkt/5igSMwxCdMXi zeK6wrCVAIPPwCrknCtPl2OypS/fz9M995iSJiBRQnyc7dyF6qgxfbhvyoc7k+gw58gh sWVAW37jpWrcgwzj6Kq6myCiBNko8s1bvfgVt1icNNwXBd77uVotSQEb0EVPMgj5XJ4m qUrqlJzFLPQNwHWcGbOFoFCkkaIcxbRsD08HCfkQDL9vdno2WHgvb1NdpJz6MySsjNLX puUw== 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:arc-authentication-results; bh=sRdoOoYX/dpvkyB7W+2vJ9ZehzWiItCHvjm/+OrYc5s=; b=nbPQ/hIZ6FS91rwzk0K6ou0tephCOB5i0zLDFOWCCX4w8f2mwoXH8cgTQ1IFjldcXs +QskrK5EDya8u+SBmgSTlqsvppMVoeaC3TvIe4olP2NJY38G38+Z0hTt3zWdAmCoLOTQ 8SyE+6pEQWi8C4IcAlZ827LxTKzCgWLxpeheBrPOuE1RrslKuqMZJ49YpRg9W5Zvkrec g6U0vUBXyy5zR7+sXq6Wn7JAEyn+4yivjn7SAV7ZFvq9yypksNHGRtoxZxOrZk2xLm5y AGMlCandJhlbkRH25dVQB8GgUY0M5JL/+ldTCwuDyNyny6tSgRI490NGmfkLcQIjbM6m 524Q== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g16-v6si157776pgv.78.2018.07.16.23.39.12; Mon, 16 Jul 2018 23:39:50 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729633AbeGQHGh (ORCPT + 99 others); Tue, 17 Jul 2018 03:06:37 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:35760 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728309AbeGQHGh (ORCPT ); Tue, 17 Jul 2018 03:06:37 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1ffJZp-0005am-L8; Tue, 17 Jul 2018 14:35:13 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1ffJZd-0003AG-6y; Tue, 17 Jul 2018 14:35:01 +0800 Date: Tue, 17 Jul 2018 14:35:01 +0800 From: Herbert Xu To: Kees Cook Cc: Arnd Bergmann , Eric Biggers , "Gustavo A. R. Silva" , Alasdair Kergon , Giovanni Cabiddu , Lars Persson , Mike Snitzer , Rabin Vincent , Tim Chen , linux-crypto@vger.kernel.org, qat-linux@intel.com, dm-devel@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 01/11] crypto: xcbc: Remove VLA usage Message-ID: <20180717063501.exqa54plsfjl4s73@gondor.apana.org.au> References: <20180717042150.37761-1-keescook@chromium.org> <20180717042150.37761-2-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180717042150.37761-2-keescook@chromium.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 16, 2018 at 09:21:40PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this uses > the maximum blocksize and adds a sanity check. For xcbc, the blocksize > must always be 16, so use that, since it's already being enforced during > instantiation. > > [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com > > Signed-off-by: Kees Cook > --- > crypto/xcbc.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/crypto/xcbc.c b/crypto/xcbc.c > index 25c75af50d3f..7aa03beed795 100644 > --- a/crypto/xcbc.c > +++ b/crypto/xcbc.c > @@ -57,6 +57,8 @@ struct xcbc_desc_ctx { > u8 ctx[]; > }; > > +#define XCBC_BLOCKSIZE 16 > + > static int crypto_xcbc_digest_setkey(struct crypto_shash *parent, > const u8 *inkey, unsigned int keylen) > { > @@ -65,7 +67,10 @@ static int crypto_xcbc_digest_setkey(struct crypto_shash *parent, > int bs = crypto_shash_blocksize(parent); > u8 *consts = PTR_ALIGN(&ctx->ctx[0], alignmask + 1); > int err = 0; > - u8 key1[bs]; > + u8 key1[XCBC_BLOCKSIZE]; > + > + if (WARN_ON(bs > sizeof(key1))) > + return -EINVAL; Please remove this. You already checked it in xcbc_create. In fact, you should just make bs XCBC_BLOCKSIZE unconditinoally in this function. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt