[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1500065429.3755.3.camel@gmail.com>
Date: Fri, 14 Jul 2017 16:50:29 -0400
From: Daniel Micay <danielmicay@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Kees Cook <keescook@...omium.org>
Cc: Dave Jones <davej@...emonkey.org.uk>,
Anna Schumaker <schumaker.anna@...il.com>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"J. Bruce Fields" <bfields@...ldses.org>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com
Subject: Re: [GIT PULL] Please pull NFS client changes for Linux 4.13
> 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.
Powered by blists - more mailing lists