| Message ID | 20230831-strncpy-arch-arm64-v3-1-cdbb1e7ea5e1@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v3] arm64/sysreg: refactor deprecated strncpy | expand |
Hi Justin, On Thu, Aug 31, 2023 at 10:55:59PM +0000, Justin Stitt wrote: > strncpy is deprecated [1] and should not be used if the src string is > not NUL-terminated. > > When dealing with `cmdline` we are counting the number of characters > until a space then copying these over into `buf`. Let's not use any of > the str*() functions since the src string is not necessarily NUL-terminated. > > Prefer `memcpy()` alongside a forced NUL-termination as it more > accurately describes what is going on within this function, i.e: copying > from non NUL-terminated buffer into a NUL-terminated buffer. > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Suggested-by: Kees Cook <keescook@chromium.org> > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Here's a quick rundown on the history of this patch: > 1) v1 (changes requested) > 2) v2 (applied to arm64 (for-next/misc)) > 3) v2 reverted (https://lore.kernel.org/all/20230831162227.2307863-1-smostafa@google.com/) This is just a patch, it is not reverted yet, also Marc replied with another proposal to use strscpy instead but with the correct length. > 4) v3 (fixes problems with both v1 and v2) > > Changes in v3: > - Fix faulty logic and use memcpy over strscpy (thanks Mostafa and Kees) > - Use '\0' instead of 0 to make it abundantly clear that `buf` is a NUL-terminated string > - Link to v2: https://lore.kernel.org/r/20230811-strncpy-arch-arm64-v2-1-ba84eabffadb@google.com > > Changes in v2: > - Utilize return value from strscpy and check for truncation (thanks Kees) > - Link to v1: https://lore.kernel.org/r/20230810-strncpy-arch-arm64-v1-1-f67f3685cd64@google.com > --- > arch/arm64/kernel/idreg-override.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c > index 2fe2491b692c..3addc09f8746 100644 > --- a/arch/arm64/kernel/idreg-override.c > +++ b/arch/arm64/kernel/idreg-override.c > @@ -263,8 +263,8 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases) > return; > > len = min(len, ARRAY_SIZE(buf) - 1); > - strncpy(buf, cmdline, len); > - buf[len] = 0; > + memcpy(buf, cmdline, len); > + buf[len] = '\0'; > > if (strcmp(buf, "--") == 0) > return; > > --- > base-commit: 706a741595047797872e669b3101429ab8d378ef > change-id: 20230810-strncpy-arch-arm64-1f3d328bd9b8 Your patch will not apply on mainline but on the revert, otherwise Tested-by: Mostafa Saleh <smostafa@google.com> > Best regards, > -- > Justin Stitt <justinstitt@google.com> Thanks, Mostafa
On Fri, Sep 01, 2023 at 12:09:19PM +0000, Mostafa Saleh wrote: > On Thu, Aug 31, 2023 at 10:55:59PM +0000, Justin Stitt wrote: > > diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c > > index 2fe2491b692c..3addc09f8746 100644 > > --- a/arch/arm64/kernel/idreg-override.c > > +++ b/arch/arm64/kernel/idreg-override.c > > @@ -263,8 +263,8 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases) > > return; > > > > len = min(len, ARRAY_SIZE(buf) - 1); > > - strncpy(buf, cmdline, len); > > - buf[len] = 0; > > + memcpy(buf, cmdline, len); > > + buf[len] = '\0'; > > > > if (strcmp(buf, "--") == 0) > > return; > > > > --- > > base-commit: 706a741595047797872e669b3101429ab8d378ef > > change-id: 20230810-strncpy-arch-arm64-1f3d328bd9b8 > > Your patch will not apply on mainline but on the revert, otherwise > > Tested-by: Mostafa Saleh <smostafa@google.com> If somebody can post a v4 based against mainline, then I'm happy to pick it up as a fix. Thanks. Will
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c index 2fe2491b692c..3addc09f8746 100644 --- a/arch/arm64/kernel/idreg-override.c +++ b/arch/arm64/kernel/idreg-override.c @@ -263,8 +263,8 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases) return; len = min(len, ARRAY_SIZE(buf) - 1); - strncpy(buf, cmdline, len); - buf[len] = 0; + memcpy(buf, cmdline, len); + buf[len] = '\0'; if (strcmp(buf, "--") == 0) return;
strncpy is deprecated [1] and should not be used if the src string is not NUL-terminated. When dealing with `cmdline` we are counting the number of characters until a space then copying these over into `buf`. Let's not use any of the str*() functions since the src string is not necessarily NUL-terminated. Prefer `memcpy()` alongside a forced NUL-termination as it more accurately describes what is going on within this function, i.e: copying from non NUL-terminated buffer into a NUL-terminated buffer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Justin Stitt <justinstitt@google.com> --- Here's a quick rundown on the history of this patch: 1) v1 (changes requested) 2) v2 (applied to arm64 (for-next/misc)) 3) v2 reverted (https://lore.kernel.org/all/20230831162227.2307863-1-smostafa@google.com/) 4) v3 (fixes problems with both v1 and v2) Changes in v3: - Fix faulty logic and use memcpy over strscpy (thanks Mostafa and Kees) - Use '\0' instead of 0 to make it abundantly clear that `buf` is a NUL-terminated string - Link to v2: https://lore.kernel.org/r/20230811-strncpy-arch-arm64-v2-1-ba84eabffadb@google.com Changes in v2: - Utilize return value from strscpy and check for truncation (thanks Kees) - Link to v1: https://lore.kernel.org/r/20230810-strncpy-arch-arm64-v1-1-f67f3685cd64@google.com --- arch/arm64/kernel/idreg-override.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- base-commit: 706a741595047797872e669b3101429ab8d378ef change-id: 20230810-strncpy-arch-arm64-1f3d328bd9b8 Best regards, -- Justin Stitt <justinstitt@google.com>