From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5108C43381 for ; Thu, 14 Feb 2019 22:51:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A48521B68 for ; Thu, 14 Feb 2019 22:51:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550184709; bh=IZP3At8REBAADSCF/mRXaWkOtngg6gG1+9CIrIyi/h4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:In-Reply-To: References:List-ID:From; b=MYSlWxgCjKjahxb34s3yaoCdaeQHQaj6sFZmG4BY1otj2Uhuyh3qP3DBItHhF4VzQ c20dUMZ6LgX+x7gcjejjGeJzaB6wLutyu8Qhd9+PUSPuSLHirQKgoH8x+1gXom2SS2 n3GSPg22bry83yhz0d+2G8rFFNJl/6SEHS5Kh+YE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726085AbfBNWvs (ORCPT ); Thu, 14 Feb 2019 17:51:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:50826 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725818AbfBNWvs (ORCPT ); Thu, 14 Feb 2019 17:51:48 -0500 Received: from localhost.localdomain (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5988F21872; Thu, 14 Feb 2019 22:51:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550184707; bh=IZP3At8REBAADSCF/mRXaWkOtngg6gG1+9CIrIyi/h4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:In-Reply-To: References:From; b=Xbr6AYOZpSuCYyoMbMFuXmVclNxrZoRGUS7g1452B7dgtlRvXkKhn8GKowqU37lrc UYXFvTeKuFk0COW9kPfOCn5lbK37y/VUWGu+CRsRtAmsEvt0Jthsj+4LOgy3mJBFq2 CbCPHaXg3yCjtfmckHSicaWIP8DuSjAhMhVgUBgs= From: Masami Hiramatsu To: stable@vger.kernel.org Cc: andreas.ziegler@fau.de, mhiramat@kernel.org, mingo@redhat.com, rostedt@goodmis.org Subject: [PATCH stable-4.9 v2] tracing/uprobes: Fix output for multiple string arguments Date: Fri, 15 Feb 2019 07:51:24 +0900 Message-Id: <155018468387.22962.2955652204936873199.stgit@devbox> X-Mailer: git-send-email 2.13.6 In-Reply-To: <155015033547.18674.8589980281201075511.stgit@devbox> References: <155015033547.18674.8589980281201075511.stgit@devbox> In-Reply-To: <155015033547.18674.8589980281201075511.stgit@devbox> References: <155015033547.18674.8589980281201075511.stgit@devbox> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Andreas Ziegler 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 Cc: stable@vger.kernel.org Fixes: 5baaa59ef09e ("tracing/probes: Implement 'memory' fetch method for uprobes") Acked-by: Masami Hiramatsu Signed-off-by: Andreas Ziegler Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Masami Hiramatsu --- 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 f0ab801a6437..c6eee3d9ed00 100644 --- a/kernel/trace/trace_uprobe.c +++ b/kernel/trace/trace_uprobe.c @@ -150,7 +150,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';