Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
MIME-Version: 1.0
References: <20230919192156.121503-1-azeems@google.com>
In-Reply-To: <20230919192156.121503-1-azeems@google.com>
From:   Justin Stitt <justinstitt@google.com>
Date:   Tue, 19 Sep 2023 20:21:05 -0700
Message-ID: <CAFhGd8oDsU6wyEqXLQVgTWALp9Hun=3gjcki+ZFSu7ihjpZ_XA@mail.gmail.com>
Subject: Re: [PATCH v2] vt: Replace strlcpy with strscpy
To:     Azeem Shaikh <azeems@google.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-serial@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Tony Luck <tony.luck@intel.com>,
        Kefeng Wang <wangkefeng.wang@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Sep 19, 2023 at 12:22=E2=80=AFPM Azeem Shaikh <azeems@google.com> w=
rote:
>
> strlcpy() reads the entire source buffer first and returns the size of
> the source string, not the destination string, which can be accidentally
> misused [1].
>
> The copy_to_user() call uses @len returned from strlcpy() directly
> without checking its value. This could potentially lead to read
> overflow. There is no existing bug since @len is always guaranteed to be
> greater than hardcoded strings in @func_table[kb_func]. But as written
> it is very fragile and specifically uses a strlcpy() result without sanit=
y
> checking and using it to copy to userspace.
>
> In an effort to remove strlcpy() completely [2], replace
> strlcpy() here with strscpy().
>
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcp=
y
> [2] https://github.com/KSPP/linux/issues/89
>
> Signed-off-by: Azeem Shaikh <azeems@google.com>
Reviewed-by: Justin Stitt <justinstitt@google.com>

> ---
> v2:
>  * Return -ENOSPC instead of -EFAULT in case of truncation.
>  * Update commit log to clarify that there is no exploitable bug but inst=
ead the code uses a fragile anti-pattern.
>
> v1:
>  * https://lore.kernel.org/all/20230830160410.3820390-1-azeemshaikh38@gma=
il.com/
>
>  drivers/tty/vt/keyboard.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index 1fe6107b539b..12a192e1196b 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -2079,12 +2079,15 @@ int vt_do_kdgkb_ioctl(int cmd, struct kbsentry __=
user *user_kdgkb, int perm)
>                         return -ENOMEM;
>
>                 spin_lock_irqsave(&func_buf_lock, flags);
> -               len =3D strlcpy(kbs, func_table[kb_func] ? : "", len);
> +               len =3D strscpy(kbs, func_table[kb_func] ? : "", len);
>                 spin_unlock_irqrestore(&func_buf_lock, flags);
>
> +               if (len < 0) {
> +                       ret =3D -ENOSPC;
> +                       break;
> +               }
>                 ret =3D copy_to_user(user_kdgkb->kb_string, kbs, len + 1)=
 ?
>                         -EFAULT : 0;
> -
>                 break;
>         }
>         case KDSKBSENT:
> --
> 2.42.0.459.ge4e396fd5e-goog
>
>

whitespace nitpicks: A newline after the newly added if-statement's
ending curly brace as well as reinstating the removed newline in your
diff might make the code look "better".

Thanks
Justin