linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer
@ 2018-10-17 12:10 Michael Ellerman
  2018-10-17 12:26 ` Jann Horn
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Michael Ellerman @ 2018-10-17 12:10 UTC (permalink / raw)
  To: rostedt; +Cc: linux-kernel, kernel-hardening

Currently seq_buf_puts() will happily create a non NULL terminated
string for you in the buffer. This is particularly dangerous if the
buffer is on the stack.

For example:

  char buf[8];
  char secret = "secret";
  struct seq_buf s;

  seq_buf_init(&s, buf, sizeof(buf));
  seq_buf_puts(&s, "foo");
  printk("Message is %s\n", buf);

Can result in:

  Message is fooªªªªªsecret

We could require all users to memset() their buffer to NULL before
use. But that seems likely to be forgotten and lead to bugs.

Instead we can change seq_buf_puts() to always leave the buffer in a
NULL terminated state.

The only downside is that this makes the buffer 1 character smaller
for seq_buf_puts(), but that seems like a good trade off.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 lib/seq_buf.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

I recently merged a patch which actually hit this behaviour. I worked
around it by using seq_buf_printf(), but it would be good to fix the
problem at the source.

diff --git a/lib/seq_buf.c b/lib/seq_buf.c
index 11f2ae0f9099..b1570204cde3 100644
--- a/lib/seq_buf.c
+++ b/lib/seq_buf.c
@@ -144,9 +144,13 @@ int seq_buf_puts(struct seq_buf *s, const char *str)
 
 	WARN_ON(s->size == 0);
 
+	/* Add 1 to len for the trailing NULL which must be there */
+	len += 1;
+
 	if (seq_buf_can_fit(s, len)) {
 		memcpy(s->buffer + s->len, str, len);
-		s->len += len;
+		/* Don't count the trailing NULL against the capacity */
+		s->len += len - 1;
 		return 0;
 	}
 	seq_buf_set_overflow(s);
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer
  2018-10-17 12:10 [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer Michael Ellerman
@ 2018-10-17 12:26 ` Jann Horn
  2018-10-17 12:42   ` Steven Rostedt
  2018-10-19  4:17   ` Michael Ellerman
  2018-10-17 14:48 ` Steven Rostedt
  2018-10-19  0:35 ` Kees Cook
  2 siblings, 2 replies; 6+ messages in thread
From: Jann Horn @ 2018-10-17 12:26 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: Steven Rostedt, kernel list, Kernel Hardening

On Wed, Oct 17, 2018 at 2:10 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Currently seq_buf_puts() will happily create a non NULL terminated
> string for you in the buffer. This is particularly dangerous if the
> buffer is on the stack.
>
> For example:
>
>   char buf[8];
>   char secret = "secret";
>   struct seq_buf s;
>
>   seq_buf_init(&s, buf, sizeof(buf));
>   seq_buf_puts(&s, "foo");
>   printk("Message is %s\n", buf);
>
> Can result in:
>
>   Message is fooªªªªªsecret
>
> We could require all users to memset() their buffer to NULL before
> use. But that seems likely to be forgotten and lead to bugs.
>
> Instead we can change seq_buf_puts() to always leave the buffer in a
> NULL terminated state.
>
> The only downside is that this makes the buffer 1 character smaller
> for seq_buf_puts(), but that seems like a good trade off.

After this, you can also simplify rdt_last_cmd_status_show(), right?

> ---
>  lib/seq_buf.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> I recently merged a patch which actually hit this behaviour. I worked
> around it by using seq_buf_printf(), but it would be good to fix the
> problem at the source.
>
> diff --git a/lib/seq_buf.c b/lib/seq_buf.c
> index 11f2ae0f9099..b1570204cde3 100644
> --- a/lib/seq_buf.c
> +++ b/lib/seq_buf.c
> @@ -144,9 +144,13 @@ int seq_buf_puts(struct seq_buf *s, const char *str)
>
>         WARN_ON(s->size == 0);
>
> +       /* Add 1 to len for the trailing NULL which must be there */

Nit: In the comments, I would prefer either "null byte" or "NUL"
instead of "NULL" when talking about something that is not a pointer.

> +       len += 1;

It looks like you're using an "unsigned int" for the length, meaning
that this can in theory (e.g. when operating on a string from a big
vmalloc buffer) overflow. You should be using size_t here.

>         if (seq_buf_can_fit(s, len)) {
>                 memcpy(s->buffer + s->len, str, len);
> -               s->len += len;
> +               /* Don't count the trailing NULL against the capacity */
> +               s->len += len - 1;
>                 return 0;
>         }
>         seq_buf_set_overflow(s);
> --
> 2.17.1
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer
  2018-10-17 12:26 ` Jann Horn
@ 2018-10-17 12:42   ` Steven Rostedt
  2018-10-19  4:17   ` Michael Ellerman
  1 sibling, 0 replies; 6+ messages in thread
From: Steven Rostedt @ 2018-10-17 12:42 UTC (permalink / raw)
  To: Jann Horn; +Cc: Michael Ellerman, kernel list, Kernel Hardening

On Wed, 17 Oct 2018 14:26:37 +0200
Jann Horn <jannh@google.com> wrote:

> > diff --git a/lib/seq_buf.c b/lib/seq_buf.c
> > index 11f2ae0f9099..b1570204cde3 100644
> > --- a/lib/seq_buf.c
> > +++ b/lib/seq_buf.c
> > @@ -144,9 +144,13 @@ int seq_buf_puts(struct seq_buf *s, const char *str)
> >
> >         WARN_ON(s->size == 0);
> >
> > +       /* Add 1 to len for the trailing NULL which must be there */  
> 
> Nit: In the comments, I would prefer either "null byte" or "NUL"
> instead of "NULL" when talking about something that is not a pointer.
> 
> > +       len += 1;  
> 
> It looks like you're using an "unsigned int" for the length, meaning
> that this can in theory (e.g. when operating on a string from a big
> vmalloc buffer) overflow. You should be using size_t here.

seq_buf is not meant for gigabytes of data. We'll change it when that
ever happens.

-- Steve


> 
> >         if (seq_buf_can_fit(s, len)) {
> >                 memcpy(s->buffer + s->len, str, len);
> > -               s->len += len;
> > +               /* Don't count the trailing NULL against the capacity */
> > +               s->len += len - 1;
> >                 return 0;
> >         }
> >         seq_buf_set_overflow(s);
> > --
> > 2.17.1
> >  


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer
  2018-10-17 12:10 [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer Michael Ellerman
  2018-10-17 12:26 ` Jann Horn
@ 2018-10-17 14:48 ` Steven Rostedt
  2018-10-19  0:35 ` Kees Cook
  2 siblings, 0 replies; 6+ messages in thread
From: Steven Rostedt @ 2018-10-17 14:48 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: linux-kernel, kernel-hardening

On Wed, 17 Oct 2018 23:10:00 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:

> Currently seq_buf_puts() will happily create a non NULL terminated
> string for you in the buffer. This is particularly dangerous if the
> buffer is on the stack.
> 
> For example:
> 
>   char buf[8];
>   char secret = "secret";
>   struct seq_buf s;
> 
>   seq_buf_init(&s, buf, sizeof(buf));
>   seq_buf_puts(&s, "foo");
>   printk("Message is %s\n", buf);
> 
> Can result in:
> 
>   Message is fooªªªªªsecret
> 
> We could require all users to memset() their buffer to NULL before
> use. But that seems likely to be forgotten and lead to bugs.
> 
> Instead we can change seq_buf_puts() to always leave the buffer in a
> NULL terminated state.
> 
> The only downside is that this makes the buffer 1 character smaller
> for seq_buf_puts(), but that seems like a good trade off.
> 
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>

It's been on my todo list for some time, and that was to add this
(trace-cmd had this for years). Would this be useful?

Instead of always writing a nul pointer, just terminate it when you are
done.


-- Steve


diff --git a/lib/seq_buf.c b/lib/seq_buf.c
index 11f2ae0f9099..46f2a8b3e733 100644
--- a/lib/seq_buf.c
+++ b/lib/seq_buf.c
@@ -175,6 +175,29 @@ int seq_buf_putc(struct seq_buf *s, unsigned char c)
 }
 
 /**
+ * seq_buf_terminate - force the buffer to end in a nul character
+ * @s: seq_buf descriptor
+ *
+ * Make sure the current buffer terminates with a nul '\0' character.
+ * This does not increment the length of the buffer.
+ *
+ * Returns 0 if there was room to add the nul character.
+ *        -1 if there was not room. But a nul character was
+ *           still added, overwriting the last character in the buffer.
+ */
+int seq_buf_terminate(struct seq_buf *s)
+{
+	WARN_ON(s->size == 0);
+
+	if (seq_buf_can_fit(s, 1)) {
+		s->buffer[s->len] = '\0';
+		return 0;
+	}
+	s->buffer[--s->len] = '\0';
+	return -1;
+}
+
+/**
  * seq_buf_putmem - write raw data into the sequenc buffer
  * @s: seq_buf descriptor
  * @mem: The raw memory to copy into the buffer

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer
  2018-10-17 12:10 [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer Michael Ellerman
  2018-10-17 12:26 ` Jann Horn
  2018-10-17 14:48 ` Steven Rostedt
@ 2018-10-19  0:35 ` Kees Cook
  2 siblings, 0 replies; 6+ messages in thread
From: Kees Cook @ 2018-10-19  0:35 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: Steven Rostedt, LKML, Kernel Hardening

On Wed, Oct 17, 2018 at 5:10 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Currently seq_buf_puts() will happily create a non NULL terminated
> string for you in the buffer. This is particularly dangerous if the
> buffer is on the stack.
>
> For example:
>
>   char buf[8];
>   char secret = "secret";
>   struct seq_buf s;
>
>   seq_buf_init(&s, buf, sizeof(buf));
>   seq_buf_puts(&s, "foo");
>   printk("Message is %s\n", buf);
>
> Can result in:
>
>   Message is fooªªªªªsecret
>
> We could require all users to memset() their buffer to NULL before
> use. But that seems likely to be forgotten and lead to bugs.
>
> Instead we can change seq_buf_puts() to always leave the buffer in a
> NULL terminated state.
>
> The only downside is that this makes the buffer 1 character smaller
> for seq_buf_puts(), but that seems like a good trade off.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Yes, please! :) I prefer keeping the string terminated over needing to
remember to do it later.

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

> ---
>  lib/seq_buf.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> I recently merged a patch which actually hit this behaviour. I worked
> around it by using seq_buf_printf(), but it would be good to fix the
> problem at the source.
>
> diff --git a/lib/seq_buf.c b/lib/seq_buf.c
> index 11f2ae0f9099..b1570204cde3 100644
> --- a/lib/seq_buf.c
> +++ b/lib/seq_buf.c
> @@ -144,9 +144,13 @@ int seq_buf_puts(struct seq_buf *s, const char *str)
>
>         WARN_ON(s->size == 0);
>
> +       /* Add 1 to len for the trailing NULL which must be there */
> +       len += 1;
> +
>         if (seq_buf_can_fit(s, len)) {
>                 memcpy(s->buffer + s->len, str, len);
> -               s->len += len;
> +               /* Don't count the trailing NULL against the capacity */
> +               s->len += len - 1;
>                 return 0;
>         }
>         seq_buf_set_overflow(s);
> --
> 2.17.1
>



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer
  2018-10-17 12:26 ` Jann Horn
  2018-10-17 12:42   ` Steven Rostedt
@ 2018-10-19  4:17   ` Michael Ellerman
  1 sibling, 0 replies; 6+ messages in thread
From: Michael Ellerman @ 2018-10-19  4:17 UTC (permalink / raw)
  To: Jann Horn; +Cc: Steven Rostedt, kernel list, Kernel Hardening

Jann Horn <jannh@google.com> writes:
> On Wed, Oct 17, 2018 at 2:10 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Currently seq_buf_puts() will happily create a non NULL terminated
>> string for you in the buffer. This is particularly dangerous if the
>> buffer is on the stack.
>>
>> For example:
>>
>>   char buf[8];
>>   char secret = "secret";
>>   struct seq_buf s;
>>
>>   seq_buf_init(&s, buf, sizeof(buf));
>>   seq_buf_puts(&s, "foo");
>>   printk("Message is %s\n", buf);
>>
>> Can result in:
>>
>>   Message is fooªªªªªsecret
>>
>> We could require all users to memset() their buffer to NULL before
>> use. But that seems likely to be forgotten and lead to bugs.
>>
>> Instead we can change seq_buf_puts() to always leave the buffer in a
>> NULL terminated state.
>>
>> The only downside is that this makes the buffer 1 character smaller
>> for seq_buf_puts(), but that seems like a good trade off.
>
> After this, you can also simplify rdt_last_cmd_status_show(), right?

Yes.

We also have a seq_buf_printf() in powerpc code that is printing a fixed
string purely to get NULL termination, so that can become a
seq_buf_puts().

>> diff --git a/lib/seq_buf.c b/lib/seq_buf.c
>> index 11f2ae0f9099..b1570204cde3 100644
>> --- a/lib/seq_buf.c
>> +++ b/lib/seq_buf.c
>> @@ -144,9 +144,13 @@ int seq_buf_puts(struct seq_buf *s, const char *str)
>>
>>         WARN_ON(s->size == 0);
>>
>> +       /* Add 1 to len for the trailing NULL which must be there */
>
> Nit: In the comments, I would prefer either "null byte" or "NUL"
> instead of "NULL" when talking about something that is not a pointer.

Hmm yeah I guess. I think of them as being more or less the same thing,
or at least interchangeable, but that's a bit sloppy.

I'll send a v2 with "null byte".

>> +       len += 1;
>
> It looks like you're using an "unsigned int" for the length, meaning
> that this can in theory (e.g. when operating on a string from a big
> vmalloc buffer) overflow. You should be using size_t here.

Yes you're right.

And if len overflows to zero above ..

>>         if (seq_buf_can_fit(s, len)) {

This will return true.

>>                 memcpy(s->buffer + s->len, str, len);
>> -               s->len += len;
>> +               /* Don't count the trailing NULL against the capacity */
>> +               s->len += len - 1;

And then here s->len becomes UINT_MAX.

I think. Which is probably not what we want.

I'll send a patch to switch to size_t in there.

cheers

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-10-19  4:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-17 12:10 [PATCH] seq_buf: Make seq_buf_puts() NULL terminate the buffer Michael Ellerman
2018-10-17 12:26 ` Jann Horn
2018-10-17 12:42   ` Steven Rostedt
2018-10-19  4:17   ` Michael Ellerman
2018-10-17 14:48 ` Steven Rostedt
2018-10-19  0:35 ` Kees Cook

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).