From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753129AbbIJEtZ (ORCPT ); Thu, 10 Sep 2015 00:49:25 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:34295 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750813AbbIJEtX (ORCPT ); Thu, 10 Sep 2015 00:49:23 -0400 Message-ID: <55F10B9F.6000703@oracle.com> Date: Thu, 10 Sep 2015 00:48:31 -0400 From: Sasha Levin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Zijlstra , mingo@kernel.org CC: vincent.weaver@maine.edu, eranian@google.com, jolsa@redhat.com, kan.liang@intel.com, linux-kernel@vger.kernel.org, Andrew Hunter , Maria Dimakopoulou Subject: Re: [PATCH 01/10] perf,x86: Fix event/group validation References: <20150521111710.475482798@infradead.org> <20150521111932.592505273@infradead.org> <55D78AA0.6000106@oracle.com> In-Reply-To: <55D78AA0.6000106@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ping? On 08/21/2015 04:31 PM, Sasha Levin wrote: > On 05/21/2015 07:17 AM, Peter Zijlstra wrote: >> --- a/arch/x86/kernel/cpu/perf_event_intel.c >> +++ b/arch/x86/kernel/cpu/perf_event_intel.c >> @@ -2106,7 +2106,7 @@ static struct event_constraint * >> intel_get_event_constraints(struct cpu_hw_events *cpuc, int idx, >> struct perf_event *event) >> { >> - struct event_constraint *c1 = event->hw.constraint; >> + struct event_constraint *c1 = cpuc->event_constraint[idx]; >> struct event_constraint *c2; > > Hey Peter, > > I was chasing a memory corruption in this area and I think I found > a possible culprit: > > After this patch, In the code above, we'd access "cpuc->event_constraint[idx]" > and read/change memory. > > The problem is that a valid value for idx is also -1, which isn't checked > here, so we end up accessing and possibly corrupting memory that isn't ours. > > > Thanks, > Sasha >