linux-kernel - Re: [PATCH] crypto: hisilicon - fix strncpy warning with strlcpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200604061811.GA28759@gondor.apana.org.au>
Date:   Thu, 4 Jun 2020 16:18:11 +1000
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Zhangfei Gao <zhangfei.gao@...aro.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        wangzhou1 <wangzhou1@...ilicon.com>,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        kbuild-all@...ts.01.org
Subject: Re: [PATCH] crypto: hisilicon - fix strncpy warning with strlcpy

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 <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt