From: Kees Cook <keescook@chromium.org>
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>
Subject: Re: [PATCH v2] vt: Replace strlcpy with strscpy
Date: Wed, 20 Sep 2023 08:13:28 -0700 [thread overview]
Message-ID: <202309200813.1B0C125@keescook> (raw)
In-Reply-To: <20230919192156.121503-1-azeems@google.com>
On Tue, Sep 19, 2023 at 07:21:56PM +0000, Azeem Shaikh wrote:
> 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 sanity
> 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#strlcpy
> [2] https://github.com/KSPP/linux/issues/89
>
> Signed-off-by: Azeem Shaikh <azeems@google.com>
> ---
> v2:
> * Return -ENOSPC instead of -EFAULT in case of truncation.
> * Update commit log to clarify that there is no exploitable bug but instead the code uses a fragile anti-pattern.
Changes look good. Thanks!
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
prev parent reply other threads:[~2023-09-20 15:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 19:21 [PATCH v2] vt: Replace strlcpy with strscpy Azeem Shaikh
2023-09-20 3:21 ` Justin Stitt
2023-09-20 15:13 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202309200813.1B0C125@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=azeems@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.