Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1063287ybg; Wed, 3 Jun 2020 23:19:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAwjXGbdVouAwfdRyqsEKTSmPh0H8bKuivb3rdC3ArNffqAn1eKiKlQvN827gN2lWwuTWF X-Received: by 2002:a17:906:bcf3:: with SMTP id op19mr2503276ejb.208.1591251547405; Wed, 03 Jun 2020 23:19:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591251547; cv=none; d=google.com; s=arc-20160816; b=oaGD+OuRfNNvZwtSAxGhbRIsxyNDYm33mmJ+nOlXuY0RkoAxJoQyPj8e2kqmCvT8nZ Wd57nC4rGkykZPARldDteuTgsJHPtHFS1OVjXkpan1l+XsYTPFgQIcI3X2PU26ihmiY/ Xg19nM9dGI0Gtw6E5rTPtchWw+kCdvXpGOl25BTjaHQGoMjkcTfUpq+eyxCaqf0YcjGR dY+kXyFqHbugZ1w9bY3ir69wtGUkdx7VaxduVBC0tI58rklM2Gc0slCGEmtZ2XF9sj3o eml5IM0fakp+S1rydmOgW+/a0v1wZf/Qtb381rUSQz6oGsRjFllqZpYRsOorkpcPBoxE yR6g== 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; bh=mAxyGgU5k4L2BiH3/ANwqzT+pnR2yDwtFywrZ71Q9mQ=; b=LnDtG57aJDuAIqCiygtss8i84mEGkk5S58d3SRmYKmlEkPvGiSENSnBBfhWA4O/hHl jU6jn2WISGQqTWzcWAu5uyIa5Tq/a9M29w3x8gL63O7H7bY52a7wUf04UhZy3KWBt9gb +RDgQC7CmJLXkH3BX3VUxgM3ydDmyE/MNbir9Gwy/cc8j5qHX7AMveOPOpWrW6Nu3h4a 90KMULqM7zu/Os4Wo8/BD9ic9HaUuNCWn1QxUxplvN5wVsgu7GZYclxciRoyk7Sw+H1j c7fygrcbEcXuIPaKSVeY1vWjIK2gSyzaKLZGhtszztm8LA+VJn2dXtjiOzdGq4eeUQrH 7t2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y14si1079145edu.550.2020.06.03.23.18.43; Wed, 03 Jun 2020 23:19:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726977AbgFDGSk (ORCPT + 99 others); Thu, 4 Jun 2020 02:18:40 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:36224 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725959AbgFDGSj (ORCPT ); Thu, 4 Jun 2020 02:18:39 -0400 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.0.7]) by fornost.hmeau.com with smtp (Exim 4.92 #5 (Debian)) id 1jgjCd-0002F3-44; Thu, 04 Jun 2020 16:18:12 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Thu, 04 Jun 2020 16:18:11 +1000 Date: Thu, 4 Jun 2020 16:18:11 +1000 From: Herbert Xu To: Zhangfei Gao Cc: Greg Kroah-Hartman , Jonathan Cameron , wangzhou1 , linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, kbuild-all@lists.01.org Subject: Re: [PATCH] crypto: hisilicon - fix strncpy warning with strlcpy Message-ID: <20200604061811.GA28759@gondor.apana.org.au> References: <202006032110.BEbKqovX%lkp@intel.com> <1591241524-6452-1-git-send-email-zhangfei.gao@linaro.org> <20200604033918.GA2286@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Jun 04, 2020 at 02:10:37PM +0800, Zhangfei Gao wrote: > > > Should this even allow truncation? Perhaps it'd be better to fail > > in case of an overrun? > I think we do not need consider overrun, since it at most copy size-1 bytes > to dest. > From the manual: strlcpy() > ?????? This? function? is? similar? to? strncpy(), but it copies at most > size-1 bytes to dest, always adds a terminating null > ?????? byte, > And simple tested with smaller SIZE of interface.name,? only SIZE-1 is > copied, so it is safe. > -#define UACCE_MAX_NAME_SIZE??? 64 > +#define UACCE_MAX_NAME_SIZE??? 4 That's not what I meant. As it is if you do exceed the limit the name is silently truncated. Wouldn't it be better to fail the allocation instead? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt