[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADmuW3UQ-wqobay34PY+myyk1Pr7s-cf7b-U7TUCnarEf+jsxg@mail.gmail.com>
Date: Fri, 12 May 2023 16:34:54 -0400
From: Azeem Shaikh <azeemshaikh38@...il.com>
To: Chuck Lever III <chuck.lever@...cle.com>
Cc: Jeff Layton <jlayton@...nel.org>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] NFSD: Remove all occurences of strlcpy
Resending as plain text.
> >> strlcpy() reads the entire source buffer first.
> >> This read may exceed the destination size limit.
> >> This is both inefficient and can lead to linear read
> >> overflows if a source string is not NUL-terminated [1].
> >> In an effort to remove strlcpy() completely [2], replace
> >> strlcpy here.
> >
> > Let's update the patch description. This change is really
> > a clean up -- it doesn't address the memory issues you
> > originally described.
>
> Unless, of course, you intend to apply this patch /after/
> a patch that fixes __assign_str(). In that case, no change
> to the patch description is needed.
No, I plan to land this patch before attempting to fix __assign_str itself.
Let me know if the below description looks good to you and I'll send
over a v3 patch:
[PATCH v3] NFSD: Remove open coding of string copy
Instead of open coding a __dynamic_array(), use the __string() and
__assign_str()
helper macros that exist for this kind of use case.
Part of an effort to remove deprecated strlcpy() [1] completely from the
kernel[2].
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
[2] https://github.com/KSPP/linux/issues/89
Fixes: 3c92fba557c6 ("NFSD: Enhance the nfsd_cb_setup tracepoint")
Signed-off-by: Azeem Shaikh <azeemshaikh38@...il.com>
Powered by blists - more mailing lists