Messages in this thread | | | From | Chuck Lever III <> | Subject | Re: [PATCH v2] NFSD: Remove all occurences of strlcpy | Date | Sat, 13 May 2023 02:22:06 +0000 |
| |
> On May 12, 2023, at 1:34 PM, Azeem Shaikh <azeemshaikh38@gmail.com> wrote: > > 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@gmail.com>
This looks good to me. So you'd like me to take this through the nfsd tree, possibly for 6.4-rc ?
-- Chuck Lever
| |