Return-Path: Received: from mail-qt0-f196.google.com ([209.85.216.196]:34753 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbdGNUuc (ORCPT ); Fri, 14 Jul 2017 16:50:32 -0400 Message-ID: <1500065429.3755.3.camel@gmail.com> Subject: Re: [GIT PULL] Please pull NFS client changes for Linux 4.13 From: Daniel Micay To: Linus Torvalds , Andrey Ryabinin , Kees Cook Cc: Dave Jones , Anna Schumaker , Linux NFS Mailing List , linux-fsdevel , Linux Kernel Mailing List , "J. Bruce Fields" , Alexander Potapenko , Dmitry Vyukov , kasan-dev@googlegroups.com Date: Fri, 14 Jul 2017 16:50:29 -0400 In-Reply-To: <1500064716.3755.1.camel@gmail.com> References: <20170714142543.k5xcbnb4mww3sxpy@codemonkey.org.uk> <4c68e120-5ada-6ce1-30fd-e26155c9704e@virtuozzo.com> <1500064716.3755.1.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org List-ID: > My initial patch used strlcpy there, because I wasn't aware of strscpy > before it was suggested: > > http://www.openwall.com/lists/kernel-hardening/2017/05/04/11 > > I was wrong to move it to strscpy. It could be switched back to > strlcpy > again unless the kernel considers the count parameter to be a > guarantee > that could be leveraged in the future. Using the fortified strlen + > memcpy would provide the improvement that strscpy was meant to provide > there over strlcpy. Similarly, the FORTIFY_SOURCE strcat uses strlcat with the assumption that the count parameter is a limit, not a guarantee for a optimization. There's only a C implementation and it currently doesn't, but if it's meant to be a guarantee then the strcat needs to be changed too. I'll make a fix moving away both from the existing functions.