[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202308301421.997C4034B5@keescook>
Date: Wed, 30 Aug 2023 14:28:21 -0700
From: Kees Cook <keescook@...omium.org>
To: Azeem Shaikh <azeemshaikh38@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-serial@...r.kernel.org,
Kefeng Wang <wangkefeng.wang@...wei.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] vt: Fix potential read overflow of kernel memory
On Wed, Aug 30, 2023 at 03:25:54PM -0400, Azeem Shaikh wrote:
> On Wed, Aug 30, 2023 at 1:57 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >
> > On Wed, Aug 30, 2023 at 04:04:10PM +0000, Azeem Shaikh wrote:
> > > strlcpy() reads the entire source buffer first.
> > > This read may exceed the destination size limit if
> > > a source string is not NUL-terminated [1].
> >
> > But that's not the case here, right? So your "potential read overflow"
> > isn't relevant here.
> >
> > > The copy_to_user() call uses @len returned from strlcpy() directly
> > > without checking its value. This could potentially lead to read
> > > overflow.
> >
> > But can it? How?
> >
>
> The case I was considering is when the null-terminated hardcoded
> string @func_table[kb_func] has length @new_len > @len. In this case,
> strlcpy() will assign @len = @new_len and copy_to_user() would read
> @new_len from the kmalloc-ed memory of @len. This is the potential
> read overflow I was referring to. Let me know if I'm mistaken.
First there is:
ssize_t len = sizeof(user_kdgkb->kb_string);
"struct user_kdgkb" is UAPI (therefore unlikely to change), and kb_string
is 512:
struct kbsentry {
unsigned char kb_func;
unsigned char kb_string[512];
};
Then we do:
len = strlcpy(kbs, func_table[kb_func] ? : "", len);
This is the anti-pattern (take the length of the _source_) we need to
remove. However, func_table[] is made up of either %NUL-terminated
strings:
char func_buf[] = {
'\033', '[', '[', 'A', 0,
'\033', '[', '[', 'B', 0,
...
char *func_table[MAX_NR_FUNC] = {
func_buf + 0,
func_buf + 5,
...
Or a NULL address itself. The ?: operator handles the NULL case, so
"len" can only ever be 0 through the longest string in func_buf. So it's
what I'd call "accidentally correct". i.e. it's using a fragile
anti-pattern, but in this case everything is hard-coded and less than
512.
Regardless, we need to swap for a sane pattern, which you've done. But
the commit log is misleading, so it needs some more detail. :)
-Kees
--
Kees Cook
Powered by blists - more mailing lists