All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Ziegler <andreas.ziegler@fau.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@redhat.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	linux-kernel@vger.kernel.org,
	Andreas Ziegler <andreas.ziegler@fau.de>
Subject: [PATCH] tracing/uprobes: Fix output for multiple string arguments
Date: Wed, 16 Jan 2019 10:41:12 +0100	[thread overview]
Message-ID: <20190116094112.16043-1-andreas.ziegler@fau.de> (raw)
In-Reply-To: <8b67136d-28d7-a734-6366-9511e30d66a7@fau.de>

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.

Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
---
 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 e335576b9411..dfb9bbc7fd82 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 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++;
 		*(u32 *)dest = make_data_loc(ret, (void *)dst - base);
 	}
 
-- 
2.17.1


  reply	other threads:[~2019-01-16  9:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14 12:38 uprobes: bug in comm/string output? Andreas Ziegler
2019-01-15 13:36 ` Andreas Ziegler
2019-01-16  9:41   ` Andreas Ziegler [this message]
2019-01-16 13:40     ` [PATCH] tracing/uprobes: Fix output for multiple string arguments Steven Rostedt
2019-01-16 14:13       ` Andreas Ziegler
2019-01-16 14:16       ` [PATCH v2] " Andreas Ziegler
2019-01-16 14:34         ` Steven Rostedt
2019-01-17  6:01         ` Masami Hiramatsu
2019-01-17  7:40           ` Andreas Ziegler
2019-01-17  7:58             ` Masami Hiramatsu
2019-01-17 14:20               ` Steven Rostedt
2019-01-17 14:29                 ` Andreas Ziegler
2019-01-17 14:51                   ` Steven Rostedt
2019-01-17 15:14                     ` Andreas Ziegler
2019-01-17 15:35                       ` Steven Rostedt
2019-01-16 10:00   ` uprobes: bug in comm/string output? Masami Hiramatsu
2019-01-16 10:16     ` Andreas Ziegler
2019-01-17  6:13       ` Masami Hiramatsu
2019-01-17  8:00         ` Masami Hiramatsu
2019-01-17  8:08           ` Andreas Ziegler
2019-01-17  9:47             ` Masami Hiramatsu
2019-01-17 13:44               ` Andreas Ziegler
2019-01-17 13:47                 ` Greg Kroah-Hartman
2019-01-17 23:50                 ` Masami Hiramatsu

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=20190116094112.16043-1-andreas.ziegler@fau.de \
    --to=andreas.ziegler@fau.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    /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.