Received: by 10.192.165.156 with SMTP id m28csp1147091imm; Wed, 11 Apr 2018 13:19:11 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/3m90WNXgozb3YKMJDjPKOKSSBGHXP4X9iI0YsL6v2uZCqd8kGGGfEh0ZUTDv1bn9FbEiV X-Received: by 10.99.95.5 with SMTP id t5mr4444040pgb.295.1523477951083; Wed, 11 Apr 2018 13:19:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523477951; cv=none; d=google.com; s=arc-20160816; b=rWgNtd6OH278+8ZvDw4gQbcu3jjs7rP4taKoyeoQs4mX+kAQe4RSkKGvxdnxfe1mzx 01cR9mBpl+mNNFT68yX16JTIHJex/fPA+kWBRoY/bDIv0Pur9NdjGxHKWIln+MMbxJKw HFAJ/vNub8A6kB+N3VDiO1pnvGGDDsa4lPyzGqoxOIYylI+WwGIS0MJRYM43eAlD66rP VoeSGtARngVe22kxDyycCcmLMcPR3e5UNXCmfqJvQMBb1CeTHMF1JjhLxpUn2a6+Hh3S ORI0STZlhIYrShKhUzi94Z3G6KBEHZ59pAujsyMwGGSUVjtl+EdIx/g7Obx4BqqyRFsO V0mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=EZrh37yBe25putkMX9c7uKdQgs50CY+jidUrKcvT420=; b=qZ3vba+Ku6Q225mdH0cHreRFrcoqvZFTqmPY9EXcqtW9kyRCN+0tJbQTQ6DQnZjJqB x8oOevcjDfrtM5IpvfZaTGeALQKAmne9BS2Hg8/27QyE+0YcKXroMKaCqDdGKBePUx+I 67buJLr3lbydlTh+LMnl87Hy24k85tgLZNYYsZin+BXnIi9jCCL9KjaBTa9hU3QYYEbq +DGQpocnpOGzoWvzd5S4sxw6ssmBKzcO2T1HKKcQdRknitmAoyj3osw+gzf4/n7gp38l yC1l4bhYOEywbXP3Xg8+n9SvNDriI5oMMEZ/7suKZnYRSwiwMOB6AhDJ7UkUakisz/AZ d4rQ== 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 a84si1399545pfl.154.2018.04.11.13.18.33; Wed, 11 Apr 2018 13:19:11 -0700 (PDT) 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 S933343AbeDKSxo (ORCPT + 99 others); Wed, 11 Apr 2018 14:53:44 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33916 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933318AbeDKSxl (ORCPT ); Wed, 11 Apr 2018 14:53:41 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 70B01E70; Wed, 11 Apr 2018 18:53:40 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Al Viro , Will Deacon , Peter Zijlstra , Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , Linus Torvalds , Thomas Gleixner , Ingo Molnar , Sasha Levin Subject: [PATCH 4.9 028/310] perf/callchain: Force USER_DS when invoking perf_callchain_user() Date: Wed, 11 Apr 2018 20:32:47 +0200 Message-Id: <20180411183623.502566763@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180411183622.305902791@linuxfoundation.org> References: <20180411183622.305902791@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Will Deacon [ Upstream commit 88b0193d9418c00340e45e0a913a0813bc6c8c96 ] Perf can generate and record a user callchain in response to a synchronous request, such as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we can end up walking the user stack (and dereferencing/saving whatever we find there) without the protections usually afforded by checks such as access_ok. Rather than play whack-a-mole with each architecture's stack unwinding implementation, fix the root of the problem by ensuring that we force USER_DS when invoking perf_callchain_user from the perf core. Reported-by: Al Viro Signed-off-by: Will Deacon Acked-by: Peter Zijlstra Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- kernel/events/callchain.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/kernel/events/callchain.c +++ b/kernel/events/callchain.c @@ -227,12 +227,18 @@ get_perf_callchain(struct pt_regs *regs, } if (regs) { + mm_segment_t fs; + if (crosstask) goto exit_put; if (add_mark) perf_callchain_store_context(&ctx, PERF_CONTEXT_USER); + + fs = get_fs(); + set_fs(USER_DS); perf_callchain_user(&ctx, regs); + set_fs(fs); } }