| Message ID | 20231019-strncpy-drivers-pnp-pnpbios-rsparser-c-v1-1-e47d93b52e3e@google.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 50cbdaf1b93a2cc89d7712feafa76cf1b2f28adc |
| Headers | show |
| Series | PNP: replace deprecated strncpy with memcpy | expand |
On Thu, Oct 19, 2023 at 11:28:32PM +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 > interfaces. > > After having precisely calculated the lengths and ensuring we don't > overflow the buffer, this really decays to just a memcpy. Let's not use > a C string api as it makes the intention of the code confusing. This is another case where we're building a C string from a byte array. > It'd be nice to use strscpy() in this case (as we clearly want > NUL-termination) because it'd clean up the code a bit. However, I don't > quite know enough about what is going on here to justify a drop-in > replacement -- too much bit magic and why (PNP_NAME_LEN - 2)? I'm afraid > using strscpy() may result in copying too many or too few bytes into our > dev->name buffer resulting in different behavior. At least using > memcpy() we can ensure the behavior is exactly the same. > > Side note: > NUL-padding is not required because insert_device() calls > pnpbios_parse_data_stream() with a zero-allocated `dev`: > 299 | static int __init insert_device(struct pnp_bios_node *node) { > ... > 312 | dev = pnp_alloc_dev(&pnpbios_protocol, node->handle, id); > ... > 316 | pnpbios_parse_data_stream(dev, node); > > then pnpbios_parse_data_stream() calls pnpbios_parse_compatible_ids(). > > 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 > Signed-off-by: Justin Stitt <justinstitt@google.com> tl;dr: Reviewed-by: Kees Cook <keescook@chromium.org> My ramblings below... > --- > Note: build-tested only. > > Found with: $ rg "strncpy\(" > --- > drivers/pnp/pnpbios/rsparser.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/pnp/pnpbios/rsparser.c b/drivers/pnp/pnpbios/rsparser.c > index 2f31b212b1a5..70af7821d3fa 100644 > --- a/drivers/pnp/pnpbios/rsparser.c > +++ b/drivers/pnp/pnpbios/rsparser.c > @@ -454,8 +454,8 @@ static unsigned char *pnpbios_parse_compatible_ids(unsigned char *p, > switch (tag) { So we've got a fixed-sized C string as a destination: struct pnp_dev { ... char name[PNP_NAME_LEN]; /* contains a human-readable name */ include/linux/pnp.h:#define PNP_NAME_LEN 50 And a funky "source length" calculation, which appears to be effectively a u16 (it's either the low 3 bits of a u8, or a full u16); int len ... /* determine the type of tag */ if (p[0] & LARGE_TAG) { /* large tag */ len = (p[2] << 8) | p[1]; tag = p[0]; } else { /* small tag */ len = p[0] & 0x07; tag = ((p[0] >> 3) & 0x0f); } The old code was doing: case LARGE_TAG_ANSISTR: strncpy(dev->name, p + 3, len >= PNP_NAME_LEN ? PNP_NAME_LEN - 2 : len); dev->name[len >= PNP_NAME_LEN ? PNP_NAME_LEN - 1 : len] = '\0'; break; The two conditionals are not the same -- the first is -2, the latter is -1, but only when len >= PNP_NAME_LEN. This smells like a bug? For the len >= PNP_NAME_LEN case, it will copy 48 bytes and then write a %NUL to index 49 (byte 50). ... ... source byte 49 is ignored for no reason I can see. Regardless, the point is to copy no more than min(len, PNP_NAME_LEN - 1) from "p + 3" to not overflow dev->name, and leaving it %NUL terminated. So, I think what you have is identical behavior, and likely still contains the 1 byte short bug, which I think is fine to keep as-is since it's been like this forever and it's PNP... -Kees
On Fri, Oct 20, 2023 at 2:31 AM Kees Cook <keescook@chromium.org> wrote: > > On Thu, Oct 19, 2023 at 11:28:32PM +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 > > interfaces. > > > > After having precisely calculated the lengths and ensuring we don't > > overflow the buffer, this really decays to just a memcpy. Let's not use > > a C string api as it makes the intention of the code confusing. > > This is another case where we're building a C string from a byte array. > > > It'd be nice to use strscpy() in this case (as we clearly want > > NUL-termination) because it'd clean up the code a bit. However, I don't > > quite know enough about what is going on here to justify a drop-in > > replacement -- too much bit magic and why (PNP_NAME_LEN - 2)? I'm afraid > > using strscpy() may result in copying too many or too few bytes into our > > dev->name buffer resulting in different behavior. At least using > > memcpy() we can ensure the behavior is exactly the same. > > > > Side note: > > NUL-padding is not required because insert_device() calls > > pnpbios_parse_data_stream() with a zero-allocated `dev`: > > 299 | static int __init insert_device(struct pnp_bios_node *node) { > > ... > > 312 | dev = pnp_alloc_dev(&pnpbios_protocol, node->handle, id); > > ... > > 316 | pnpbios_parse_data_stream(dev, node); > > > > then pnpbios_parse_data_stream() calls pnpbios_parse_compatible_ids(). > > > > 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 > > Signed-off-by: Justin Stitt <justinstitt@google.com> > > tl;dr: > > Reviewed-by: Kees Cook <keescook@chromium.org> > > My ramblings below... > > > --- > > Note: build-tested only. > > > > Found with: $ rg "strncpy\(" > > --- > > drivers/pnp/pnpbios/rsparser.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/pnp/pnpbios/rsparser.c b/drivers/pnp/pnpbios/rsparser.c > > index 2f31b212b1a5..70af7821d3fa 100644 > > --- a/drivers/pnp/pnpbios/rsparser.c > > +++ b/drivers/pnp/pnpbios/rsparser.c > > @@ -454,8 +454,8 @@ static unsigned char *pnpbios_parse_compatible_ids(unsigned char *p, > > switch (tag) { > > So we've got a fixed-sized C string as a destination: > > struct pnp_dev { > ... > char name[PNP_NAME_LEN]; /* contains a human-readable name */ > > include/linux/pnp.h:#define PNP_NAME_LEN 50 > > And a funky "source length" calculation, which appears to be effectively > a u16 (it's either the low 3 bits of a u8, or a full u16); > > int len ... > > /* determine the type of tag */ > if (p[0] & LARGE_TAG) { /* large tag */ > len = (p[2] << 8) | p[1]; > tag = p[0]; > } else { /* small tag */ > len = p[0] & 0x07; > tag = ((p[0] >> 3) & 0x0f); > } > > The old code was doing: > > case LARGE_TAG_ANSISTR: > strncpy(dev->name, p + 3, > len >= PNP_NAME_LEN ? PNP_NAME_LEN - 2 : len); > dev->name[len >= > PNP_NAME_LEN ? PNP_NAME_LEN - 1 : len] = '\0'; > break; > > The two conditionals are not the same -- the first is -2, the latter is > -1, but only when len >= PNP_NAME_LEN. This smells like a bug? For the > len >= PNP_NAME_LEN case, it will copy 48 bytes and then write a %NUL to > index 49 (byte 50). ... ... source byte 49 is ignored for no reason I > can see. > > Regardless, the point is to copy no more than min(len, PNP_NAME_LEN - 1) > from "p + 3" to not overflow dev->name, and leaving it %NUL terminated. > > So, I think what you have is identical behavior, and likely still > contains the 1 byte short bug, which I think is fine to keep as-is since > it's been like this forever and it's PNP... And so applied as 6.7 material, thanks!
diff --git a/drivers/pnp/pnpbios/rsparser.c b/drivers/pnp/pnpbios/rsparser.c index 2f31b212b1a5..70af7821d3fa 100644 --- a/drivers/pnp/pnpbios/rsparser.c +++ b/drivers/pnp/pnpbios/rsparser.c @@ -454,8 +454,8 @@ static unsigned char *pnpbios_parse_compatible_ids(unsigned char *p, switch (tag) { case LARGE_TAG_ANSISTR: - strncpy(dev->name, p + 3, - len >= PNP_NAME_LEN ? PNP_NAME_LEN - 2 : len); + memcpy(dev->name, p + 3, + len >= PNP_NAME_LEN ? PNP_NAME_LEN - 2 : len); dev->name[len >= PNP_NAME_LEN ? PNP_NAME_LEN - 1 : len] = '\0'; break;
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous interfaces. After having precisely calculated the lengths and ensuring we don't overflow the buffer, this really decays to just a memcpy. Let's not use a C string api as it makes the intention of the code confusing. It'd be nice to use strscpy() in this case (as we clearly want NUL-termination) because it'd clean up the code a bit. However, I don't quite know enough about what is going on here to justify a drop-in replacement -- too much bit magic and why (PNP_NAME_LEN - 2)? I'm afraid using strscpy() may result in copying too many or too few bytes into our dev->name buffer resulting in different behavior. At least using memcpy() we can ensure the behavior is exactly the same. Side note: NUL-padding is not required because insert_device() calls pnpbios_parse_data_stream() with a zero-allocated `dev`: 299 | static int __init insert_device(struct pnp_bios_node *node) { ... 312 | dev = pnp_alloc_dev(&pnpbios_protocol, node->handle, id); ... 316 | pnpbios_parse_data_stream(dev, node); then pnpbios_parse_data_stream() calls pnpbios_parse_compatible_ids(). 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 Signed-off-by: Justin Stitt <justinstitt@google.com> --- Note: build-tested only. Found with: $ rg "strncpy\(" --- drivers/pnp/pnpbios/rsparser.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- base-commit: dab3e01664eaddae965699f1fec776609db0ea9d change-id: 20231019-strncpy-drivers-pnp-pnpbios-rsparser-c-5d7343441cac Best regards, -- Justin Stitt <justinstitt@google.com>