Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4440515imm; Tue, 7 Aug 2018 01:20:07 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfEncm6hBWL/LEExUs5oRIhiEhUL4dfhrcPC+bnGfgqzhmCTUMJiN0IDkdGg6AMQ3i1JPnf X-Received: by 2002:a17:902:b7c6:: with SMTP id v6-v6mr16608390plz.49.1533630007206; Tue, 07 Aug 2018 01:20:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533630007; cv=none; d=google.com; s=arc-20160816; b=K1CO0UnGXiNrRVdDzdTVmC2dzde4n3igW6Xs/20WEPW3aPKUBC5VOTWyCyyJo6er2L PHNWg7KW54uPqsF9IOUPoFO8A6HaQCAp2FHAXjQELQImvWsmha7xqhXUplttr68G0scB MSlRhxNs9sPjv8wk9aSUVlfrz0JwMjXeihqRi30CqR4RlPyYaPqX3JZAXaqbCY07FGwP san3jlA2uEpJTZRg/JXFZYlx3wQfXJcel2B34ep0gJtbD4Kq1q/0rEuKXnn7R77huGKK Nwbur7MD0jPj54f8stxyFkSXOJKXEk6jzgLBMZieHxdrfSc0raTojzpjM3wOKEUI1Tst E6yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=qt42W0B059LUO1C3lTHe3dnox4h7YF5q2lNhh+Y5CIM=; b=b27Obdlll/6DCR/Yd85r/R2d9sQJ643o16ORbr3rtf3xn8SHpHgd4VuJbSm++/IlCu LMuS/Iz+tJiC+RVBFxndrrDCuOATkA0ZbuNEyWjGodYQ83n2uBXHcoo2u1lmkjeGurFY R71GcP9gyop/G87fQ2isHRRGi1SUT76tCyeq7SnnOiyboYzJp87l9RLnqQv1ijdpN0rd QxhjU6eKmgDTdxVLT2iZtwpf/1ZZwsaPtNKUpjbfqJEF57b2AELoYT+xmu4i2rhIAJIy C0QlWgGDCPJY/Lhp9E1TV+WPMBc86KUq+UQFkyvSWw+fyKiz3Aiwr3tpdGMd4+dO+pVz da7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aHO9s9RB; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y67-v6si818315pfa.47.2018.08.07.01.19.50; Tue, 07 Aug 2018 01:20:07 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=aHO9s9RB; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727272AbeHGK3r (ORCPT + 99 others); Tue, 7 Aug 2018 06:29:47 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:52027 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726286AbeHGK3r (ORCPT ); Tue, 7 Aug 2018 06:29:47 -0400 Received: by mail-wm0-f65.google.com with SMTP id y2-v6so16441599wma.1 for ; Tue, 07 Aug 2018 01:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qt42W0B059LUO1C3lTHe3dnox4h7YF5q2lNhh+Y5CIM=; b=aHO9s9RBg2uclKggRsS0eiqs4RLFLkQkDCSH9L2O5OLqFQnbLdx04CGaNdafTUTKDJ egZIKlnA/A0ogyUR+iGbyaZE12NRJi8GWBNmQVQDTsGf8lEOZokx6RohrqyZNiq6JQ3o 745KNhBLJ2AgZUDjLFaeEAchhyzGFLB/0Ss5rPbcvkIpR58bMTUC9zOJkkX3cTvS/71v JD24qhwhD/7syNjyBeAWp/Jt4JnuxgZqbVnJFvw21t1KLzZ4rpZkqbH5A3iWQBU1wcbn CAsPoM9qZtJrZ6XqBI+dv2sKfxuUp/HySSw738rDYwPWmi+4P6uO5aJ1WsF0ohwskoyY J7hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qt42W0B059LUO1C3lTHe3dnox4h7YF5q2lNhh+Y5CIM=; b=IRJWWHZSrOsrLY/FgoRMerBqxNXio+dp27HAjiNudqg3X4iqsYrPMlhN6h9idjUsVd T2W0xJHE3TFpy5B7umbTtAu63CPYLbTwXp0W7B3AERorNb4OSkOV8rCy0jFLBVdfVNTh vYJoASNZYlGo4R+C/OTHm9r3uuptzQfv3U3uZOSH+8l9eHYkB4hEOUdUuNRU/YQr+Fdv ffAmJojhQ82zHJsTbcW75FDNOaJkuRe4tUkhsYopYW+skswRGpunz16aKVCNIS0tHm/k lav7km8sBZgUQh7i4LqP0kMosW7hxmSZX+TKGx6GywYq8XlWIZC50Yd1frjUK5OtqyAl dNKQ== X-Gm-Message-State: AOUpUlHZjPlcRCpFLOIjcLJQXWS7dtV1A2ziEA9qiOGzxGCNje1rVpuZ 0bg06jTWOdHltSqFCvNxtuEoa6D/VfsVx3MXfHVBwdXcfoI= X-Received: by 2002:a1c:9d02:: with SMTP id g2-v6mr896590wme.122.1533629794155; Tue, 07 Aug 2018 01:16:34 -0700 (PDT) MIME-Version: 1.0 References: <1533605015-19514-1-git-send-email-eranian@google.com> <20180807072029.GA7716@krava> In-Reply-To: <20180807072029.GA7716@krava> From: Stephane Eranian Date: Tue, 7 Aug 2018 01:16:22 -0700 Message-ID: Subject: Re: [PATCH] perf ordered_events: fix crash in free_dup_event() To: Jiri Olsa Cc: LKML , Arnaldo Carvalho de Melo , Peter Zijlstra , mingo@elte.hu 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 On Tue, Aug 7, 2018 at 12:20 AM Jiri Olsa wrote: > > On Mon, Aug 06, 2018 at 06:23:35PM -0700, Stephane Eranian wrote: > > Depending on memory allocations, it was possible to get a SEGFAULT in > > free_dup_event() because the event pointer was bogus: > > > > perf[1354]: segfault at ffffffff00000006 ip 00000000004b7fc7 > > is there any reproducer? > The cmdline is simple: $ perf record -e cycles:pp -o - -a sleep 1 | perf inject -b -i - >/dev/null I was using v4.13 for my tests and it may be sensitive to compiler. Was using LLVM. It may be a compiler related issue. You do not allocate the whole struct. If the compiler was to do a memcpy() behind your back, you'd be in troubles. Adding extra padding before *event was also avoiding the problem. struct ordered_event { u64 timestamp; u64 file_offset; char pad[32]; <----- extra padding for debugging union perf_event *event; struct list_head list; }; > > > > Initially, I thought it was some double free. But it turns out > > it looked more like a buffer overrun. Adding padding before > > the union perf_event field in struct ordered_event avoided the > > problem. But it was not obvious where this could be coming from > > given the accesses to the struct, i.e., no internal array. > > > > Then, it struck me that the following was bogus in __dup_event(): > > > > __dup_event(struct ordered_events *oe, union perf_event *event) > > { > > ... > > union perf_event *new_event; > > new_event = memdup(event, event->header.size); > > ... > > } > > > > The problem here is that header.size <= sizeof(*new_event). The code > > was trying to copy only what was necessary, but then, the allocation > > hum, and I think we should continue to do so.. we can't allocate ~4000 > bytes space for 30 bytes sample > I understand that but it seems the event field gets overwritten under some conditions. > > was also only partial. In other words if the event was not the largest > > possible for the union, it would not be fully backed by memory, likely > > causing troubles. > > how? using that event allocated space for another type of event? > > > > > This patch fixes the problem by passing the size of the union and not > > that of the actual event. > > I think that's just bypassing the real issue, please share more details > on how to reproduce this > > thanks, > jirka > > > > > Signed-off-by: Stephane Eranian > > > > --- > > tools/perf/util/ordered-events.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c > > index bad9e0296e9a..a90dbe5df019 100644 > > --- a/tools/perf/util/ordered-events.c > > +++ b/tools/perf/util/ordered-events.c > > @@ -66,9 +66,9 @@ static union perf_event *__dup_event(struct ordered_events *oe, > > union perf_event *new_event = NULL; > > > > if (oe->cur_alloc_size < oe->max_alloc_size) { > > - new_event = memdup(event, event->header.size); > > + new_event = memdup(event, sizeof(*event)); > > if (new_event) > > - oe->cur_alloc_size += event->header.size; > > + oe->cur_alloc_size += sizeof(*event); > > } > > > > return new_event; > > -- > > 2.18.0.597.ga71716f1ad-goog > >