Received-SPF: pass (google.com: domain of linux-kernel+bounces-87806-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240229070757.796244-1-irogers@google.com> <CAM9d7chNekmdJyPbOOzZVhR+cBWajscSg3pVFKN4A4evKwFXjg@mail.gmail.com>
 <CAP-5=fVWC+MeeUcNmofkQi766se4P0ERGz_+L+7uTFUXocwVvQ@mail.gmail.com>
In-Reply-To: <CAP-5=fVWC+MeeUcNmofkQi766se4P0ERGz_+L+7uTFUXocwVvQ@mail.gmail.com>
From: Namhyung Kim <namhyung@kernel.org>
Date: Thu, 29 Feb 2024 17:58:09 -0800
Message-ID: <CAM9d7civC_xYw11pJc-4T2R1D=Enf0mvjLtdU5qXxfS+zB2qJQ@mail.gmail.com>
Subject: Re: [PATCH v1] libperf evlist: Avoid out-of-bounds access
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, 
	Arnaldo Carvalho de Melo <acme@kernel.org>, Mark Rutland <mark.rutland@arm.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Adrian Hunter <adrian.hunter@intel.com>, Yang Jihong <yangjihong1@huawei.com>, 
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 29, 2024 at 5:06=E2=80=AFPM Ian Rogers <irogers@google.com> wro=
te:
>
> On Thu, Feb 29, 2024 at 1:46=E2=80=AFPM Namhyung Kim <namhyung@kernel.org=
> wrote:
> >
> > On Wed, Feb 28, 2024 at 11:08=E2=80=AFPM Ian Rogers <irogers@google.com=
> wrote:
> > >
> > > Parallel testing appears to show a race between allocating and settin=
g
> > > evsel ids. As there is a bounds check on the xyarray it yields a segv
> > > like:
> > >
> > > ```
> > > AddressSanitizer:DEADLYSIGNAL
> > >
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > > =3D=3D484408=3D=3DERROR: AddressSanitizer: SEGV on unknown address 0x=
000000000010
> > >
> > > =3D=3D484408=3D=3DThe signal is caused by a WRITE memory access.
> > >
> > > =3D=3D484408=3D=3DHint: address points to the zero page.
> > >
> > >     #0 0x55cef5d4eff4 in perf_evlist__id_hash tools/lib/perf/evlist.c=
:256
> > >     #1 0x55cef5d4f132 in perf_evlist__id_add tools/lib/perf/evlist.c:=
274
> > >     #2 0x55cef5d4f545 in perf_evlist__id_add_fd tools/lib/perf/evlist=
c:315
> > >     #3 0x55cef5a1923f in store_evsel_ids util/evsel.c:3130
> > >     #4 0x55cef5a19400 in evsel__store_ids util/evsel.c:3147
> > >     #5 0x55cef5888204 in __run_perf_stat tools/perf/builtin-stat.c:83=
2
> > >     #6 0x55cef5888c06 in run_perf_stat tools/perf/builtin-stat.c:960
> > >     #7 0x55cef58932db in cmd_stat tools/perf/builtin-stat.c:2878
> > > ...
> > > ```
> > >
> > > Avoid this crash by early exiting the perf_evlist__id_add_fd and
> > > perf_evlist__id_add is the access is out-of-bounds.
> > >
> > > Signed-off-by: Ian Rogers <irogers@google.com>
> >
> > While I'm ok with this change, the real fix would be changing
> > evsel_store__ids() to use xyarray__max_{x,y} for fd instead
> > of cpu and thread map numbers.
>
> So I'm not sure on how to code that fix. Could you take over looking
> at this? It reproduces for me with "perf test -v -p" when built with
> "-fsanitize=3Daddress".

Ok, but now I think that the fd array should have the same dimension
with the id array.  I'm not sure where it can change but I'll take a look
later.  Let's apply this one first.

Thanks,
Namhyung