FAILED: patch "[PATCH] tracing/uprobes: Fix output for multiple string arguments" failed to apply to 4.19-stable tree

FAILED: patch "[PATCH] tracing/uprobes: Fix output for multiple string arguments" failed to apply to 4.19-stable tree

[gregkh]

The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 0722069a5374b904ec1a67f91249f90e1cfae259 Mon Sep 17 00:00:00 2001
From: Andreas Ziegler <andreas.ziegler@fau.de>
Date: Wed, 16 Jan 2019 15:16:29 +0100
Subject: [PATCH] tracing/uprobes: Fix output for multiple string arguments

When printing multiple uprobe arguments as strings the output for the
earlier arguments would also include all later string arguments.

This is best explained in an example:

Consider adding a uprobe to a function receiving two strings as
parameters which is at offset 0xa0 in strlib.so and we want to print
both parameters when the uprobe is hit (on x86_64):

$ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
    /sys/kernel/debug/tracing/uprobe_events

When the function is called as func("foo", "bar") and we hit the probe,
the trace file shows a line like the following:

  [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"

Note the extra "bar" printed as part of arg1. This behaviour stacks up
for additional string arguments.

The strings are stored in a dynamically growing part of the uprobe
buffer by fetch_store_string() after copying them from userspace via
strncpy_from_user(). The return value of strncpy_from_user() is then
directly used as the required size for the string. However, this does
not take the terminating null byte into account as the documentation
for strncpy_from_user() cleary states that it "[...] returns the
length of the string (not including the trailing NUL)" even though the
null byte will be copied to the destination.

Therefore, subsequent calls to fetch_store_string() will overwrite
the terminating null byte of the most recently fetched string with
the first character of the current string, leading to the
"accumulation" of strings in earlier arguments in the output.

Fix this by incrementing the return value of strncpy_from_user() by
one if we did not hit the maximum buffer size.

Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de

Cc: Ingo Molnar <mingo@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 19a1a8e19062..9bde07c06362 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -160,6 +160,13 @@ fetch_store_string(unsigned long addr, void *dest, void *base)
 	if (ret >= 0) {
 		if (ret == maxlen)
 			dst[ret - 1] = '\0';
+		else
+			/*
+			 * Include the terminating null byte. In this case it
+			 * was copied by strncpy_from_user but not accounted
+			 * for in ret.
+			 */
+			ret++;
 		*(u32 *)dest = make_data_loc(ret, (void *)dst - base);
 	}
 

[PATCH stable-4.19] tracing/uprobes: Fix output for multiple string arguments

[Masami Hiramatsu]

From: Andreas Ziegler <andreas.ziegler@fau.de>

commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.

When printing multiple uprobe arguments as strings the output for the
earlier arguments would also include all later string arguments.

This is best explained in an example:

Consider adding a uprobe to a function receiving two strings as
parameters which is at offset 0xa0 in strlib.so and we want to print
both parameters when the uprobe is hit (on x86_64):

$ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
    /sys/kernel/debug/tracing/uprobe_events

When the function is called as func("foo", "bar") and we hit the probe,
the trace file shows a line like the following:

  [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"

Note the extra "bar" printed as part of arg1. This behaviour stacks up
for additional string arguments.

The strings are stored in a dynamically growing part of the uprobe
buffer by fetch_store_string() after copying them from userspace via
strncpy_from_user(). The return value of strncpy_from_user() is then
directly used as the required size for the string. However, this does
not take the terminating null byte into account as the documentation
for strncpy_from_user() cleary states that it "[...] returns the
length of the string (not including the trailing NUL)" even though the
null byte will be copied to the destination.

Therefore, subsequent calls to fetch_store_string() will overwrite
the terminating null byte of the most recently fetched string with
the first character of the current string, leading to the
"accumulation" of strings in earlier arguments in the output.

Fix this by incrementing the return value of strncpy_from_user() by
one if we did not hit the maximum buffer size.

Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de

Cc: Ingo Molnar <mingo@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
 kernel/trace/trace_uprobe.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e696667da29a..04c1769a8c7c 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -142,6 +142,13 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
 	ret = strncpy_from_user(dst, src, maxlen);
 	if (ret == maxlen)
 		dst[--ret] = '\0';
+	else if (ret >= 0)
+		/*
+		 * Include the terminating null byte. In this case it
+		 * was copied by strncpy_from_user but not accounted
+		 * for in ret.
+		 */
+		ret++;
 
 	if (ret < 0) {	/* Failed to fetch string */
 		((u8 *)get_rloc_data(dest))[0] = '\0';

Re: [PATCH stable-4.19] tracing/uprobes: Fix output for multiple string arguments

[Andreas Ziegler]

Hi,

> 
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index e696667da29a..04c1769a8c7c 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -142,6 +142,13 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
>   	ret = strncpy_from_user(dst, src, maxlen);
>   	if (ret == maxlen)
>   		dst[--ret] = '\0';
> +	else if (ret >= 0)

with this fix the maxlen case still decrements ret by one which does not 
include the terminating \0 (and leaves maxlen = 1 in 
store_trace_args()). Usually this only happens with the last element but 
I still feel that it's inconsistent...

Would'nt it be easier to simply add a '+ 1' to to the make_rloc_data() 
statement, like this:

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e696667da29a..ca0051a84ce8 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -147,7 +147,7 @@ static void FETCH_FUNC_NAME(memory, string)(struct 
pt_regs *regs,
                 ((u8 *)get_rloc_data(dest))[0] = '\0';
                 *(u32 *)dest = make_data_rloc(0, get_rloc_offs(rloc));
         } else {
-               *(u32 *)dest = make_data_rloc(ret, get_rloc_offs(rloc));
+               *(u32 *)dest = make_data_rloc(ret + 1, get_rloc_offs(rloc));
         }
  }

> +		/*
> +		 * Include the terminating null byte. In this case it
> +		 * was copied by strncpy_from_user but not accounted
> +		 * for in ret.
> +		 */
> +		ret++;
>   
>   	if (ret < 0) {	/* Failed to fetch string */
>   		((u8 *)get_rloc_data(dest))[0] = '\0';
> 

Regards,

Andreas

Re: [PATCH stable-4.19] tracing/uprobes: Fix output for multiple string arguments

[Masami Hiramatsu]

Hi Andreas,

On Thu, 14 Feb 2019 14:00:03 +0100
Andreas Ziegler <andreas.ziegler@fau.de> wrote:

> Hi,
> 
> > 
> > diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> > index e696667da29a..04c1769a8c7c 100644
> > --- a/kernel/trace/trace_uprobe.c
> > +++ b/kernel/trace/trace_uprobe.c
> > @@ -142,6 +142,13 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
> >   	ret = strncpy_from_user(dst, src, maxlen);
> >   	if (ret == maxlen)
> >   		dst[--ret] = '\0';
> > +	else if (ret >= 0)
> 
> with this fix the maxlen case still decrements ret by one which does not 
> include the terminating \0 (and leaves maxlen = 1 in 
> store_trace_args()). Usually this only happens with the last element but 
> I still feel that it's inconsistent...

Yes, I found that too. And I thought it was another fix.

> 
> Would'nt it be easier to simply add a '+ 1' to to the make_rloc_data() 
> statement, like this:

Hmm, in that case, I would like to make "--ret" to "ret - 1" as the
latest kernel does. Keeping the final code similar will help us
if we need another fix to backport.

Any thought?

Thank you,

> 
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index e696667da29a..ca0051a84ce8 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -147,7 +147,7 @@ static void FETCH_FUNC_NAME(memory, string)(struct 
> pt_regs *regs,
>                  ((u8 *)get_rloc_data(dest))[0] = '\0';
>                  *(u32 *)dest = make_data_rloc(0, get_rloc_offs(rloc));
>          } else {
> -               *(u32 *)dest = make_data_rloc(ret, get_rloc_offs(rloc));
> +               *(u32 *)dest = make_data_rloc(ret + 1, get_rloc_offs(rloc));
>          }
>   }
> 
> > +		/*
> > +		 * Include the terminating null byte. In this case it
> > +		 * was copied by strncpy_from_user but not accounted
> > +		 * for in ret.
> > +		 */
> > +		ret++;
> >   
> >   	if (ret < 0) {	/* Failed to fetch string */
> >   		((u8 *)get_rloc_data(dest))[0] = '\0';
> > 
> 
> Regards,
> 
> Andreas


-- 
Masami Hiramatsu <mhiramat@kernel.org>

[PATCH stable-4.19 v2] tracing/uprobes: Fix output for multiple string arguments

[Masami Hiramatsu]

From: Andreas Ziegler <andreas.ziegler@fau.de>

commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.

When printing multiple uprobe arguments as strings the output for the
earlier arguments would also include all later string arguments.

This is best explained in an example:

Consider adding a uprobe to a function receiving two strings as
parameters which is at offset 0xa0 in strlib.so and we want to print
both parameters when the uprobe is hit (on x86_64):

$ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
    /sys/kernel/debug/tracing/uprobe_events

When the function is called as func("foo", "bar") and we hit the probe,
the trace file shows a line like the following:

  [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"

Note the extra "bar" printed as part of arg1. This behaviour stacks up
for additional string arguments.

The strings are stored in a dynamically growing part of the uprobe
buffer by fetch_store_string() after copying them from userspace via
strncpy_from_user(). The return value of strncpy_from_user() is then
directly used as the required size for the string. However, this does
not take the terminating null byte into account as the documentation
for strncpy_from_user() cleary states that it "[...] returns the
length of the string (not including the trailing NUL)" even though the
null byte will be copied to the destination.

Therefore, subsequent calls to fetch_store_string() will overwrite
the terminating null byte of the most recently fetched string with
the first character of the current string, leading to the
"accumulation" of strings in earlier arguments in the output.

Fix this by incrementing the return value of strncpy_from_user() by
one if we did not hit the maximum buffer size.

Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de

Cc: Ingo Molnar <mingo@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
 kernel/trace/trace_uprobe.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index e696667da29a..bf93ae152c22 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -141,7 +141,14 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
 
 	ret = strncpy_from_user(dst, src, maxlen);
 	if (ret == maxlen)
-		dst[--ret] = '\0';
+		dst[ret - 1] = '\0';
+	else if (ret >= 0)
+		/*
+		 * Include the terminating null byte. In this case it
+		 * was copied by strncpy_from_user but not accounted
+		 * for in ret.
+		 */
+		ret++;
 
 	if (ret < 0) {	/* Failed to fetch string */
 		((u8 *)get_rloc_data(dest))[0] = '\0';

Re: [PATCH stable-4.19 v2] tracing/uprobes: Fix output for multiple string arguments

[Masami Hiramatsu]

Hi Andreas,

I've update this patch to include "ret == maxlen" case fix
as similar to the latest kernel code.

Please review it. If it is OK, I'll update patches for other
stable trees.

Thank you,

On Thu, 14 Feb 2019 23:24:29 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> From: Andreas Ziegler <andreas.ziegler@fau.de>
> 
> commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
> 
> When printing multiple uprobe arguments as strings the output for the
> earlier arguments would also include all later string arguments.
> 
> This is best explained in an example:
> 
> Consider adding a uprobe to a function receiving two strings as
> parameters which is at offset 0xa0 in strlib.so and we want to print
> both parameters when the uprobe is hit (on x86_64):
> 
> $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
>     /sys/kernel/debug/tracing/uprobe_events
> 
> When the function is called as func("foo", "bar") and we hit the probe,
> the trace file shows a line like the following:
> 
>   [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
> 
> Note the extra "bar" printed as part of arg1. This behaviour stacks up
> for additional string arguments.
> 
> The strings are stored in a dynamically growing part of the uprobe
> buffer by fetch_store_string() after copying them from userspace via
> strncpy_from_user(). The return value of strncpy_from_user() is then
> directly used as the required size for the string. However, this does
> not take the terminating null byte into account as the documentation
> for strncpy_from_user() cleary states that it "[...] returns the
> length of the string (not including the trailing NUL)" even though the
> null byte will be copied to the destination.
> 
> Therefore, subsequent calls to fetch_store_string() will overwrite
> the terminating null byte of the most recently fetched string with
> the first character of the current string, leading to the
> "accumulation" of strings in earlier arguments in the output.
> 
> Fix this by incrementing the return value of strncpy_from_user() by
> one if we did not hit the maximum buffer size.
> 
> Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
> 
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: stable@vger.kernel.org
> Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
>  kernel/trace/trace_uprobe.c |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index e696667da29a..bf93ae152c22 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -141,7 +141,14 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
>  
>  	ret = strncpy_from_user(dst, src, maxlen);
>  	if (ret == maxlen)
> -		dst[--ret] = '\0';
> +		dst[ret - 1] = '\0';
> +	else if (ret >= 0)
> +		/*
> +		 * Include the terminating null byte. In this case it
> +		 * was copied by strncpy_from_user but not accounted
> +		 * for in ret.
> +		 */
> +		ret++;
>  
>  	if (ret < 0) {	/* Failed to fetch string */
>  		((u8 *)get_rloc_data(dest))[0] = '\0';
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH stable-4.19 v2] tracing/uprobes: Fix output for multiple string arguments

[Andreas Ziegler]

Hi Masami,

yes, that patch looks like a good compromise between the
original code and the new patch. To reduce the number of if 
statements involving ret we would need to move more things
around and I think it's best to avoid that (as you also said).

I'd say you can update this for the other kernel stable trees
as well.

Thank you!

Andreas

P.S.: Do we need to explain in the commit message why
backporting is needed?

> On 14. Feb 2019, at 15:30, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> Hi Andreas,
> 
> I've update this patch to include "ret == maxlen" case fix
> as similar to the latest kernel code.
> 
> Please review it. If it is OK, I'll update patches for other
> stable trees.
> 
> Thank you,
> 
> On Thu, 14 Feb 2019 23:24:29 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
>> From: Andreas Ziegler <andreas.ziegler@fau.de>
>> 
>> commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
>> 
>> When printing multiple uprobe arguments as strings the output for the
>> earlier arguments would also include all later string arguments.
>> 
>> This is best explained in an example:
>> 
>> Consider adding a uprobe to a function receiving two strings as
>> parameters which is at offset 0xa0 in strlib.so and we want to print
>> both parameters when the uprobe is hit (on x86_64):
>> 
>> $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
>>    /sys/kernel/debug/tracing/uprobe_events
>> 
>> When the function is called as func("foo", "bar") and we hit the probe,
>> the trace file shows a line like the following:
>> 
>>  [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
>> 
>> Note the extra "bar" printed as part of arg1. This behaviour stacks up
>> for additional string arguments.
>> 
>> The strings are stored in a dynamically growing part of the uprobe
>> buffer by fetch_store_string() after copying them from userspace via
>> strncpy_from_user(). The return value of strncpy_from_user() is then
>> directly used as the required size for the string. However, this does
>> not take the terminating null byte into account as the documentation
>> for strncpy_from_user() cleary states that it "[...] returns the
>> length of the string (not including the trailing NUL)" even though the
>> null byte will be copied to the destination.
>> 
>> Therefore, subsequent calls to fetch_store_string() will overwrite
>> the terminating null byte of the most recently fetched string with
>> the first character of the current string, leading to the
>> "accumulation" of strings in earlier arguments in the output.
>> 
>> Fix this by incrementing the return value of strncpy_from_user() by
>> one if we did not hit the maximum buffer size.
>> 
>> Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
>> 
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: stable@vger.kernel.org
>> Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
>> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
>> Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
>> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
>> ---
>> kernel/trace/trace_uprobe.c |    9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>> 
>> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
>> index e696667da29a..bf93ae152c22 100644
>> --- a/kernel/trace/trace_uprobe.c
>> +++ b/kernel/trace/trace_uprobe.c
>> @@ -141,7 +141,14 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
>> 
>> 	ret = strncpy_from_user(dst, src, maxlen);
>> 	if (ret == maxlen)
>> -		dst[--ret] = '\0';
>> +		dst[ret - 1] = '\0';
>> +	else if (ret >= 0)
>> +		/*
>> +		 * Include the terminating null byte. In this case it
>> +		 * was copied by strncpy_from_user but not accounted
>> +		 * for in ret.
>> +		 */
>> +		ret++;
>> 
>> 	if (ret < 0) {	/* Failed to fetch string */
>> 		((u8 *)get_rloc_data(dest))[0] = '\0';
>> 
> 
> 
> -- 
> Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH stable-4.19 v2] tracing/uprobes: Fix output for multiple string arguments

[Masami Hiramatsu]

Hi Andreas,

On Thu, 14 Feb 2019 16:53:26 +0100
Andreas Ziegler <andreas.ziegler@fau.de> wrote:

> Hi Masami,
> 
> yes, that patch looks like a good compromise between the
> original code and the new patch. To reduce the number of if 
> statements involving ret we would need to move more things
> around and I think it's best to avoid that (as you also said).
> 
> I'd say you can update this for the other kernel stable trees
> as well.

Thank you very much!

> 
> Thank you!
> 
> Andreas
> 
> P.S.: Do we need to explain in the commit message why
> backporting is needed?
> 
> > On 14. Feb 2019, at 15:30, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > 
> > Hi Andreas,
> > 
> > I've update this patch to include "ret == maxlen" case fix
> > as similar to the latest kernel code.
> > 
> > Please review it. If it is OK, I'll update patches for other
> > stable trees.
> > 
> > Thank you,
> > 
> > On Thu, 14 Feb 2019 23:24:29 +0900
> > Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > 
> >> From: Andreas Ziegler <andreas.ziegler@fau.de>
> >> 
> >> commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
> >> 
> >> When printing multiple uprobe arguments as strings the output for the
> >> earlier arguments would also include all later string arguments.
> >> 
> >> This is best explained in an example:
> >> 
> >> Consider adding a uprobe to a function receiving two strings as
> >> parameters which is at offset 0xa0 in strlib.so and we want to print
> >> both parameters when the uprobe is hit (on x86_64):
> >> 
> >> $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
> >>    /sys/kernel/debug/tracing/uprobe_events
> >> 
> >> When the function is called as func("foo", "bar") and we hit the probe,
> >> the trace file shows a line like the following:
> >> 
> >>  [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
> >> 
> >> Note the extra "bar" printed as part of arg1. This behaviour stacks up
> >> for additional string arguments.
> >> 
> >> The strings are stored in a dynamically growing part of the uprobe
> >> buffer by fetch_store_string() after copying them from userspace via
> >> strncpy_from_user(). The return value of strncpy_from_user() is then
> >> directly used as the required size for the string. However, this does
> >> not take the terminating null byte into account as the documentation
> >> for strncpy_from_user() cleary states that it "[...] returns the
> >> length of the string (not including the trailing NUL)" even though the
> >> null byte will be copied to the destination.
> >> 
> >> Therefore, subsequent calls to fetch_store_string() will overwrite
> >> the terminating null byte of the most recently fetched string with
> >> the first character of the current string, leading to the
> >> "accumulation" of strings in earlier arguments in the output.
> >> 
> >> Fix this by incrementing the return value of strncpy_from_user() by
> >> one if we did not hit the maximum buffer size.
> >> 
> >> Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
> >> 
> >> Cc: Ingo Molnar <mingo@redhat.com>
> >> Cc: stable@vger.kernel.org
> >> Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
> >> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> >> Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
> >> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> >> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> >> ---
> >> kernel/trace/trace_uprobe.c |    9 ++++++++-
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> >> index e696667da29a..bf93ae152c22 100644
> >> --- a/kernel/trace/trace_uprobe.c
> >> +++ b/kernel/trace/trace_uprobe.c
> >> @@ -141,7 +141,14 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
> >> 
> >> 	ret = strncpy_from_user(dst, src, maxlen);
> >> 	if (ret == maxlen)
> >> -		dst[--ret] = '\0';
> >> +		dst[ret - 1] = '\0';
> >> +	else if (ret >= 0)
> >> +		/*
> >> +		 * Include the terminating null byte. In this case it
> >> +		 * was copied by strncpy_from_user but not accounted
> >> +		 * for in ret.
> >> +		 */
> >> +		ret++;
> >> 
> >> 	if (ret < 0) {	/* Failed to fetch string */
> >> 		((u8 *)get_rloc_data(dest))[0] = '\0';
> >> 
> > 
> > 
> > -- 
> > Masami Hiramatsu <mhiramat@kernel.org>
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

Re: [PATCH stable-4.19 v2] tracing/uprobes: Fix output for multiple string arguments

[Greg KH]

On Thu, Feb 14, 2019 at 11:24:29PM +0900, Masami Hiramatsu wrote:
> From: Andreas Ziegler <andreas.ziegler@fau.de>
> 
> commit 0722069a5374b904ec1a67f91249f90e1cfae259 upstream.
> 
> When printing multiple uprobe arguments as strings the output for the
> earlier arguments would also include all later string arguments.
> 
> This is best explained in an example:
> 
> Consider adding a uprobe to a function receiving two strings as
> parameters which is at offset 0xa0 in strlib.so and we want to print
> both parameters when the uprobe is hit (on x86_64):
> 
> $ echo 'p:func /lib/strlib.so:0xa0 +0(%di):string +0(%si):string' > \
>     /sys/kernel/debug/tracing/uprobe_events
> 
> When the function is called as func("foo", "bar") and we hit the probe,
> the trace file shows a line like the following:
> 
>   [...] func: (0x7f7e683706a0) arg1="foobar" arg2="bar"
> 
> Note the extra "bar" printed as part of arg1. This behaviour stacks up
> for additional string arguments.
> 
> The strings are stored in a dynamically growing part of the uprobe
> buffer by fetch_store_string() after copying them from userspace via
> strncpy_from_user(). The return value of strncpy_from_user() is then
> directly used as the required size for the string. However, this does
> not take the terminating null byte into account as the documentation
> for strncpy_from_user() cleary states that it "[...] returns the
> length of the string (not including the trailing NUL)" even though the
> null byte will be copied to the destination.
> 
> Therefore, subsequent calls to fetch_store_string() will overwrite
> the terminating null byte of the most recently fetched string with
> the first character of the current string, leading to the
> "accumulation" of strings in earlier arguments in the output.
> 
> Fix this by incrementing the return value of strncpy_from_user() by
> one if we did not hit the maximum buffer size.
> 
> Link: http://lkml.kernel.org/r/20190116141629.5752-1-andreas.ziegler@fau.de
> 
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: stable@vger.kernel.org
> Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes")
> Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
> Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> ---
>  kernel/trace/trace_uprobe.c |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index e696667da29a..bf93ae152c22 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -141,7 +141,14 @@ static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
>  
>  	ret = strncpy_from_user(dst, src, maxlen);
>  	if (ret == maxlen)
> -		dst[--ret] = '\0';
> +		dst[ret - 1] = '\0';
> +	else if (ret >= 0)
> +		/*
> +		 * Include the terminating null byte. In this case it
> +		 * was copied by strncpy_from_user but not accounted
> +		 * for in ret.
> +		 */
> +		ret++;
>  
>  	if (ret < 0) {	/* Failed to fetch string */
>  		((u8 *)get_rloc_data(dest))[0] = '\0';
> 

All now queued up, thanks.

greg k-h