linux-kernel - Re: [PATCH] hfsplus: Replace strncpy with memcpy

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] [day] [month] [year] [list]

Message-ID: <1559148571.2803.73.camel@dubeyko.com>
Date:   Wed, 29 May 2019 09:49:31 -0700
From:   Viacheslav Dubeyko <slava@...eyko.com>
To:     Mathieu Malaterre <malat@...ian.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hfsplus: Replace strncpy with memcpy

On Wed, 2019-05-29 at 13:33 +0200, Mathieu Malaterre wrote:
> Function strncpy was used to copy a fixed size buffer. Since
> NUL-terminating string is not required here, prefer a memcpy
> function.
> The generated code (ppc32) remains the same.
> 
> Silence the following warning triggered using W=1:
> 
>   fs/hfsplus/xattr.c:410:3: warning: 'strncpy' output truncated
> before terminating nul copying 4 bytes from a string of the same
> length [-Wstringop-truncation]
> 
> Signed-off-by: Mathieu Malaterre <malat@...ian.org>
> ---
>  fs/hfsplus/xattr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
> index d5403b4004c9..bb0b27d88e50 100644
> --- a/fs/hfsplus/xattr.c
> +++ b/fs/hfsplus/xattr.c
> @@ -407,7 +407,7 @@ static int copy_name(char *buffer, const char
> *xattr_name, int name_len)
>  	int offset = 0;
>  
>  	if (!is_known_namespace(xattr_name)) {
> -		strncpy(buffer, XATTR_MAC_OSX_PREFIX,
> XATTR_MAC_OSX_PREFIX_LEN);
> +		memcpy(buffer, XATTR_MAC_OSX_PREFIX,
> XATTR_MAC_OSX_PREFIX_LEN);
>  		offset += XATTR_MAC_OSX_PREFIX_LEN;
>  		len += XATTR_MAC_OSX_PREFIX_LEN;
>  	}

Looks good. I don't see any troubles here.

Reviewed-by: Vyacheslav Dubeyko <slava@...eyko.com>

Thanks,
Vyacheslav Dubeyko.