| Message ID | 20240314-strncpy-drivers-soc-qcom-cmd-db-c-v1-1-70f5d5e70732@google.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | soc: qcom: cmd-db: replace deprecated strncpy with memcpy | expand |
On Thu, Mar 14, 2024 at 10:29:37PM +0000, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > @query is already marked as __nonstring and doesn't need to be > NUL-terminated. Due to this, we don't need to use a string API here > (especially a deprecated one). Let's have our stack allocation also > zero-initialize so that we can just perform a standard memcpy. Since the > code now speaks for itself we can drop the comment. A memcpy on a > __nonstring buffer explains everything that this comment talks about. > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Note: build-tested only. > > Found with: $ rg "strncpy\(" > --- > drivers/soc/qcom/cmd-db.c | 9 ++------- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c > index a5fd68411bed..512556366a3e 100644 > --- a/drivers/soc/qcom/cmd-db.c > +++ b/drivers/soc/qcom/cmd-db.c > @@ -141,18 +141,13 @@ static int cmd_db_get_header(const char *id, const struct entry_header **eh, > const struct rsc_hdr *rsc_hdr; > const struct entry_header *ent; > int ret, i, j; > - u8 query[sizeof(ent->id)] __nonstring; > + u8 query[sizeof(ent->id)] __nonstring = { 0 }; > > ret = cmd_db_ready(); > if (ret) > return ret; > > - /* > - * Pad out query string to same length as in DB. NOTE: the output > - * query string is not necessarily '\0' terminated if it bumps up > - * against the max size. That's OK and expected. > - */ > - strncpy(query, id, sizeof(query)); > + memcpy(query, id, sizeof(query)); Hm, no, this isn't right. We do want to stop copying at the first NUL character, but we don't care about truncation. e.g. imagine if "id" was a 3 character string followed by other bytes in memory. We'd copy beyond the end of "id" into query, and the later memcmp()s would start failing. I think what you want here is: strtomem(query, id); -Kees > > for (i = 0; i < MAX_SLV_ID; i++) { > rsc_hdr = &cmd_db_header->header[i]; > > --- > base-commit: fe46a7dd189e25604716c03576d05ac8a5209743 > change-id: 20240314-strncpy-drivers-soc-qcom-cmd-db-c-284f3abaabb8 > > Best regards, > -- > Justin Stitt <justinstitt@google.com> > >
On Mon, Mar 18, 2024 at 2:52 PM Kees Cook <keescook@chromium.org> wrote: > > On Thu, Mar 14, 2024 at 10:29:37PM +0000, Justin Stitt wrote: > > strncpy() is deprecated for use on NUL-terminated destination strings > > [1] and as such we should prefer more robust and less ambiguous string > > interfaces. > > > > @query is already marked as __nonstring and doesn't need to be > > NUL-terminated. Due to this, we don't need to use a string API here > > (especially a deprecated one). Let's have our stack allocation also > > zero-initialize so that we can just perform a standard memcpy. Since the > > code now speaks for itself we can drop the comment. A memcpy on a > > __nonstring buffer explains everything that this comment talks about. > > > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > Link: https://github.com/KSPP/linux/issues/90 > > Cc: linux-hardening@vger.kernel.org > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > --- > > Note: build-tested only. > > > > Found with: $ rg "strncpy\(" > > --- > > drivers/soc/qcom/cmd-db.c | 9 ++------- > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c > > index a5fd68411bed..512556366a3e 100644 > > --- a/drivers/soc/qcom/cmd-db.c > > +++ b/drivers/soc/qcom/cmd-db.c > > @@ -141,18 +141,13 @@ static int cmd_db_get_header(const char *id, const struct entry_header **eh, > > const struct rsc_hdr *rsc_hdr; > > const struct entry_header *ent; > > int ret, i, j; > > - u8 query[sizeof(ent->id)] __nonstring; > > + u8 query[sizeof(ent->id)] __nonstring = { 0 }; > > > > ret = cmd_db_ready(); > > if (ret) > > return ret; > > > > - /* > > - * Pad out query string to same length as in DB. NOTE: the output > > - * query string is not necessarily '\0' terminated if it bumps up > > - * against the max size. That's OK and expected. > > - */ > > - strncpy(query, id, sizeof(query)); > > + memcpy(query, id, sizeof(query)); > > Hm, no, this isn't right. We do want to stop copying at the first NUL > character, but we don't care about truncation. e.g. imagine if "id" was > a 3 character string followed by other bytes in memory. We'd copy beyond > the end of "id" into query, and the later memcmp()s would start failing. > I think what you want here is: > > strtomem(query, id); Gotcha, I was operating under the assumption that we needed to know the size of id at compile time. Apparently __builtin_object_size(_, 1) will return SIZE_T_MAX if we don't know the size of something. Sending a v2. > > -Kees > > > > > for (i = 0; i < MAX_SLV_ID; i++) { > > rsc_hdr = &cmd_db_header->header[i]; > > > > --- > > base-commit: fe46a7dd189e25604716c03576d05ac8a5209743 > > change-id: 20240314-strncpy-drivers-soc-qcom-cmd-db-c-284f3abaabb8 > > > > Best regards, > > -- > > Justin Stitt <justinstitt@google.com> > > > > > > -- > Kees Cook
On Mon, Mar 18, 2024 at 03:47:38PM -0700, Justin Stitt wrote: > Gotcha, I was operating under the assumption that we needed to know > the size of id at compile time. Apparently __builtin_object_size(_, 1) > will return SIZE_T_MAX if we don't know the size of something. Sending > a v2. Yeah, it only requires to know the compile-time size of the destination buffer.
diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c index a5fd68411bed..512556366a3e 100644 --- a/drivers/soc/qcom/cmd-db.c +++ b/drivers/soc/qcom/cmd-db.c @@ -141,18 +141,13 @@ static int cmd_db_get_header(const char *id, const struct entry_header **eh, const struct rsc_hdr *rsc_hdr; const struct entry_header *ent; int ret, i, j; - u8 query[sizeof(ent->id)] __nonstring; + u8 query[sizeof(ent->id)] __nonstring = { 0 }; ret = cmd_db_ready(); if (ret) return ret; - /* - * Pad out query string to same length as in DB. NOTE: the output - * query string is not necessarily '\0' terminated if it bumps up - * against the max size. That's OK and expected. - */ - strncpy(query, id, sizeof(query)); + memcpy(query, id, sizeof(query)); for (i = 0; i < MAX_SLV_ID; i++) { rsc_hdr = &cmd_db_header->header[i];
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. @query is already marked as __nonstring and doesn't need to be NUL-terminated. Due to this, we don't need to use a string API here (especially a deprecated one). Let's have our stack allocation also zero-initialize so that we can just perform a standard memcpy. Since the code now speaks for itself we can drop the comment. A memcpy on a __nonstring buffer explains everything that this comment talks about. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> --- Note: build-tested only. Found with: $ rg "strncpy\(" --- drivers/soc/qcom/cmd-db.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- base-commit: fe46a7dd189e25604716c03576d05ac8a5209743 change-id: 20240314-strncpy-drivers-soc-qcom-cmd-db-c-284f3abaabb8 Best regards, -- Justin Stitt <justinstitt@google.com>