Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp986855imu; Wed, 16 Jan 2019 10:43:40 -0800 (PST) X-Google-Smtp-Source: ALg8bN7e4jD0aEHI9PbXoMwIqH18OqyIsUtYx9GzEFVhnUmB/Pox1TMV9xzZL4C6yc7zaBqHDN6A X-Received: by 2002:a17:902:7c82:: with SMTP id y2mr11136288pll.33.1547664220000; Wed, 16 Jan 2019 10:43:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547664219; cv=none; d=google.com; s=arc-20160816; b=OafV52g9DHOadxuqzVhjtxVye60aNRIF2NcoOGeh/XDxlhWjqUNJ9cNWX4VcDgWXCr ENn3W9HESr/tnMYClFKJSRfZqkUn4anJfbD3b9cCHziedyWXm9ivyBWl/Wo8m/0448rh fhKckAgduCDyu7vlFc8dP+b+WymPoMk1kQAiCug1x4EiJrpDbW+iSuiusO+2aDD+LPFW xC+owZ2YyTbCDs7KxeYUyi40XBlt2Rv+C39zoTWAy2oNqZqA6rCQ76zyoU6H/X2eAEeb w58Rbou88hFqNEXFNq1u6jXmNNYzdYQPF/XK3hEXzjP8iPIREgvL28NTn0pXylIP7CIT YgsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=hKmunSYQWRCj6rod0KZUnqTj3kyVJ1maSG147m1QzlI=; b=Wjl6wLw3/xKszcdWAbo1EgaNlqEOJbAytVQrHPkGyZjANX+x3tOAo10GWIyaHcZWcO McVeNjWhssIwW3AWFpHdHmWHBjZSorJjXhUuzD+Hhdm4MKA9yu5wkoKpg1VKl0FlabfB Zr3F+I+t5qIZO+xqYqgluEPcRUynYNjOIafdtzqegeXkp/q+U5BJOwJoA6Q9xcrM9YYt cCn/TuIS20x5jplQktp2A8HmxMozCACNBbT/pQYMKW3OoEg52qfjtlNiKxMTyE1CmmJM vXiQdd2MJGYUOyq5/EoyQATHo009v8XeC9evWhY4Oanubl1PUiomhXxsezkFR2Ft98PV ba/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i18si6591915pgl.414.2019.01.16.10.43.23; Wed, 16 Jan 2019 10:43:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731430AbfAPJus (ORCPT + 99 others); Wed, 16 Jan 2019 04:50:48 -0500 Received: from faui40.informatik.uni-erlangen.de ([131.188.34.40]:35290 "EHLO faui40.informatik.uni-erlangen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728528AbfAPJus (ORCPT ); Wed, 16 Jan 2019 04:50:48 -0500 X-Greylist: delayed 527 seconds by postgrey-1.27 at vger.kernel.org; Wed, 16 Jan 2019 04:50:47 EST Received: from faui49copter1 (faui49copter1.informatik.uni-erlangen.de [131.188.42.149]) by faui40.informatik.uni-erlangen.de (Postfix) with SMTP id 87168548614; Wed, 16 Jan 2019 10:41:55 +0100 (CET) Received: by faui49copter1 (sSMTP sendmail emulation); Wed, 16 Jan 2019 10:41:55 +0100 From: Andreas Ziegler To: Steven Rostedt Cc: Ingo Molnar , Masami Hiramatsu , linux-kernel@vger.kernel.org, Andreas Ziegler Subject: [PATCH] tracing/uprobes: Fix output for multiple string arguments Date: Wed, 16 Jan 2019 10:41:12 +0100 Message-Id: <20190116094112.16043-1-andreas.ziegler@fau.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <8b67136d-28d7-a734-6366-9511e30d66a7@fau.de> References: <8b67136d-28d7-a734-6366-9511e30d66a7@fau.de> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED=-1 autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on faui40.informatik.uni-erlangen.de Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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