linux-kernel - Re: [PATCH v2] scsi: target: Replace strlcpy with strscpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADmuW3VbUZBRXVyZVeVuS4cbPGjfgD8fntQwMCUskR5W-CyNVQ@mail.gmail.com>
Date:   Wed, 30 Aug 2023 18:01:25 -0400
From:   Azeem Shaikh <azeemshaikh38@...il.com>
To:     Justin Stitt <justinstitt@...gle.com>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-hardening@...r.kernel.org, linux-scsi@...r.kernel.org,
        target-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] scsi: target: Replace strlcpy with strscpy

On Wed, Aug 30, 2023 at 5:53 PM Justin Stitt <justinstitt@...gle.com> wrote:
>
> On Wed, Aug 30, 2023 at 09:07:24PM +0000, Azeem Shaikh wrote:
> > 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 with strscpy().
> >
> > Direct replacement is safe here since return value of -errno
> > is used to check for truncation instead of sizeof(dest).
> >
> > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
> > [2] https://github.com/KSPP/linux/issues/89
> >
> > Signed-off-by: Azeem Shaikh <azeemshaikh38@...il.com>
> > ---
> > v2:
> >  * Replace all instances of strlcpy in this file instead of just 1.
> >
> > v1:
> >  * https://lore.kernel.org/all/20230830200717.4129442-1-azeemshaikh38@gmail.com/
> >
> >  drivers/target/target_core_configfs.c |   27 ++++++++++++---------------
> >  1 file changed, 12 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c
> > index 936e5ff1b209..10a22a428267 100644
> > --- a/drivers/target/target_core_configfs.c
> > +++ b/drivers/target/target_core_configfs.c
> > @@ -1392,16 +1392,15 @@ static ssize_t target_wwn_vendor_id_store(struct config_item *item,
> >       /* +2 to allow for a trailing (stripped) '\n' and null-terminator */
> >       unsigned char buf[INQUIRY_VENDOR_LEN + 2];
> >       char *stripped = NULL;
> > -     size_t len;
> > +     ssize_t len;
> >       ssize_t ret;
> >
> > -     len = strlcpy(buf, page, sizeof(buf));
> > -     if (len < sizeof(buf)) {
> > +     len = strscpy(buf, page, sizeof(buf));
> > +     if (len > 0) {
> >               /* Strip any newline added from userspace. */
> >               stripped = strstrip(buf);
> > -             len = strlen(stripped);
> >       }
> > -     if (len > INQUIRY_VENDOR_LEN) {
> > +     if (len < 0 || strlen(stripped) > INQUIRY_VENDOR_LEN) {
> >               pr_err("Emulated T10 Vendor Identification exceeds"
> >                       " INQUIRY_VENDOR_LEN: " __stringify(INQUIRY_VENDOR_LEN)
> >                       "\n");
>
> Should we be explicitly checking for `len == -E2BIG` instead of the more
> generic `len < 0`? Perhaps this is a nitpick but I prefer the former.
>

Most maintainers to whom I have sent such patches in the past have
preferred `len < 0` since it is not "rigid" in checking for -E2BIG
which is an implementation detail of strscpy.