Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1531907imm; Fri, 22 Jun 2018 19:54:29 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJjvDA92OCXn1Sqw7nOnEoKXB6WahhtziJz304sSqkfAEzcFt9GzLwl0OUtywdJbfzwx86M X-Received: by 2002:a17:902:bc8c:: with SMTP id bb12-v6mr4021342plb.84.1529722469013; Fri, 22 Jun 2018 19:54:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529722468; cv=none; d=google.com; s=arc-20160816; b=BYFzy5F8agC/IKlFGFmVhzHyfumQ90HjHt+srNT0W452fb1NSNnrh0cWcrFKxXWhKG GmkYKUxwX2yEpPfvC/R7axUlWs9PwfnXJ0vUfh+Hbl86Cxz6+Y1OMMrwvDmsrH0KRV9H RrzFwLpskMzGDaOth6WyRWFbZqeOVe9a4rr9L54KKjakLqsEgE920sL1OJJ1DhtYV51/ zK60/hhidflCUtz2786Hy9O+FtYpp04N+u0lwjj3TxIDmo07zkQGOpkr+CYonWOG7o6u IRpvnc+UdJzyTjdbUyLBpoo/5BTkpOqkwNDPR+mTxEyjaSyuTFiLBXby/b1mfzgfjVD6 6U1w== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=7eZrPgFfwxoWfZv2jnLxj6SQZarworewTlEBrtzBCrQ=; b=NTxg/PH888AUr/e9U/vLmSRJy9evLTwY8dDdCzhSE5xyc6sLYKOT1zYsvLQj2u7toa oYWXLx9VwkTJtVmT+MaalyTvDh/cmctb9aawhjta6tNV3PWbhEZflx3+vB3gbJALPx0m 3w3whcmeMRNpO+Ppw29PygGsNEH+TjKKeHkkzPABwXO8BMlk6wE3a+ZozyVX7DiuY058 M0JDuTESLOETwqozESH5iNQDFnMK75J2Zf6GQCmXSxLDwAF3fk617oNAdYGsewoz4NTA BBobjfxDFfJCDkAkHUeMc8YVDHkuoFth3eppdKov1mObADl7YbBwD7RdzMjqnxSU9Cgx HjcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qeyqy7S0; 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 n59-v6si8537323plb.198.2018.06.22.19.54.13; Fri, 22 Jun 2018 19:54:28 -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=qeyqy7S0; 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 S934738AbeFWCxA (ORCPT + 99 others); Fri, 22 Jun 2018 22:53:00 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:38276 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934670AbeFWCw7 (ORCPT ); Fri, 22 Jun 2018 22:52:59 -0400 Received: by mail-pl0-f67.google.com with SMTP id d10-v6so4296157plo.5; Fri, 22 Jun 2018 19:52:58 -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:content-transfer-encoding:in-reply-to :user-agent; bh=7eZrPgFfwxoWfZv2jnLxj6SQZarworewTlEBrtzBCrQ=; b=qeyqy7S08PTM1CiGMRdDbDoVFMCpa3Ap+F3rZybGBZHGuD/Ki/Rd0GczjeoFArEkia FJHx9UmjIaQAYMaoSav76q/QMhYpxldwHHqzHifSgyZnwO/MUjfkrlIt+AFh/cys4w9g tUZKnF9vXIYK2RgZq58589Bcg+RleY934XiyChnZ4sbpiIFtesqgE6Q2yU+lbPZra5Qy i+Jrczr13Kr6HUTHcbq/jixkr434dtbXKMZ44tNf0b3SWVfosPWMIrdJzwvU1LK6WzVB o+ZSFfXyGFyzaBXkEUgRP5JKJ2SwpUXwmJyjU1ezhZ0/U4W4GM25I54ZRv9scmt/sYoI ONPQ== 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:content-transfer-encoding :in-reply-to:user-agent; bh=7eZrPgFfwxoWfZv2jnLxj6SQZarworewTlEBrtzBCrQ=; b=B9LZc6ZBvucK1uT5i8M5QcMWSqr72KKt3triSc3woOGOnB4WaTt0uvg3BTyxowEXkl GIcjsNXLHsPgfJwxqfRlN2FNn7bv7FR5QG+/U5KCaYJSbMor7Kz7PKwrVjSCNpzApEQZ 0H8DyYCsb9V5BOaOabETAqvjdgOq9QfMpoBdM50apq2ldum5KHRRmx+ylxjsngHCd4el 4TsGk29xt1pdxLpy8TjDseJSS5gExOgDAa5Cr6v3bNypaL0unjRBTLVWoJaXLR9Ir5y4 mueyQBhLMVNWRY/XLNCS4JrRu0JIsjDB51onTD9uFAYKyaYEZB6qoSIo9T0fySGfH9dg rvsg== X-Gm-Message-State: APt69E2ugbniq8dMrQPWCh0p3EohYz55vE9htbURzPbc+5N4g6f9I84u 076rrA6ia/qH16D1dHZ282s= X-Received: by 2002:a17:902:76c4:: with SMTP id j4-v6mr3911378plt.19.1529722378464; Fri, 22 Jun 2018 19:52:58 -0700 (PDT) Received: from localhost (g134.124-44-9.ppp.wakwak.ne.jp. [124.44.9.134]) by smtp.gmail.com with ESMTPSA id c4-v6sm18427257pfe.53.2018.06.22.19.52.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 22 Jun 2018 19:52:58 -0700 (PDT) Date: Sat, 23 Jun 2018 11:52:56 +0900 From: Stafford Horne To: Eric Biggers Cc: LKML , Greg KH , arnd@arndb.de, linux-crypto@vger.kernel.org, Herbert Xu , "David S. Miller" , Nick Desaulniers Subject: Re: [RFC PATCH 1/2] crypto: Fix -Wstringop-truncation warnings Message-ID: <20180623025256.GG24595@lianli.shorne-pla.net> References: <20180623020753.27266-1-shorne@gmail.com> <20180623020753.27266-2-shorne@gmail.com> <20180623024149.GB880@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180623024149.GB880@sol.localdomain> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 22, 2018 at 07:41:49PM -0700, Eric Biggers wrote: > On Sat, Jun 23, 2018 at 11:07:52AM +0900, Stafford Horne wrote: > > As of GCC 9.0.0 the build is reporting warnings like: > > > > crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’: > > crypto/ablkcipher.c:374:2: warning: ‘strncpy’ specified bound 64 equals destination size [-Wstringop-truncation] > > strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "", > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > sizeof(rblkcipher.geniv)); > > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > This means the strnycpy might create a non null terminated string. Fix this by > > limiting the size of the string copy to include the null terminator. > > > > Cc: Greg Kroah-Hartman > > Cc: Arnd Bergmann > > Signed-off-by: Stafford Horne > > --- > > crypto/ablkcipher.c | 4 ++-- > > crypto/blkcipher.c | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c > > index d880a4897159..972cd7c879f6 100644 > > --- a/crypto/ablkcipher.c > > +++ b/crypto/ablkcipher.c > > @@ -372,7 +372,7 @@ static int crypto_ablkcipher_report(struct sk_buff *skb, struct crypto_alg *alg) > > > > strncpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type)); > > strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "", > > - sizeof(rblkcipher.geniv)); > > + sizeof(rblkcipher.geniv) - 1); > > > > rblkcipher.blocksize = alg->cra_blocksize; > > rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize; > > @@ -446,7 +446,7 @@ static int crypto_givcipher_report(struct sk_buff *skb, struct crypto_alg *alg) > > > > strncpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type)); > > strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "", > > - sizeof(rblkcipher.geniv)); > > + sizeof(rblkcipher.geniv) - 1); > > > > rblkcipher.blocksize = alg->cra_blocksize; > > rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize; > > diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c > > index 01c0d4aa2563..f1644b5cf68c 100644 > > --- a/crypto/blkcipher.c > > +++ b/crypto/blkcipher.c > > @@ -511,7 +511,7 @@ static int crypto_blkcipher_report(struct sk_buff *skb, struct crypto_alg *alg) > > > > strncpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type)); > > strncpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "", > > - sizeof(rblkcipher.geniv)); > > + sizeof(rblkcipher.geniv) - 1); > > > > rblkcipher.blocksize = alg->cra_blocksize; > > rblkcipher.min_keysize = alg->cra_blkcipher.min_keysize; > > Your "fix" introduces an information disclosure bug, as it results in > uninitialized memory being copied to userspace. This same broken patch was sent > by someone else too. > > Maybe it would be best to just memset() the crypto_report_* structs to 0 after > declaration and then replace the strncpy()'s with strscpy()'s, even if just to > stop people from sending broken "fixes". Do you want to do that? Right, I didnt realize that we were using strncpy to also init the whole buffer. I will do as suggest, and respic. -Stafford