From: Namhyung Kim <namhyung@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Michael Petlan <mpetlan@redhat.com>,
Wade Mealing <wmealing@redhat.com>
Subject: Re: [PATCH] perf: Fix race in perf_mmap_close function
Date: Fri, 11 Sep 2020 12:05:10 +0900 [thread overview]
Message-ID: <CAM9d7ciEAA_3Quo1-q7hU=Te+hBgJ2wYAjbDazXd7yS70HrhPA@mail.gmail.com> (raw)
In-Reply-To: <20200910144744.GA1663813@krava>
Hi Jiri,
On Thu, Sep 10, 2020 at 11:50 PM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Thu, Sep 10, 2020 at 10:48:02PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > > _do_fork+0x83/0x3a0
> > > __do_sys_wait4+0x83/0x90
> > > __do_sys_clone+0x85/0xa0
> > > do_syscall_64+0x5b/0x1e0
> > > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > >
> > > Using atomic decrease and check instead of separated calls.
> > > This fixes CVE-2020-14351.
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > > ---
> > > kernel/events/core.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 7ed5248f0445..29313cc54d9e 100644
> > > --- a/kernel/events/core.c
> > > +++ b/kernel/events/core.c
> > > @@ -5903,8 +5903,6 @@ static void perf_mmap_close(struct vm_area_struct *vma)
> > > mutex_unlock(&event->mmap_mutex);
> > > }
> > >
> > > - atomic_dec(&rb->mmap_count);
> > > -
> > > if (!atomic_dec_and_mutex_lock(&event->mmap_count, &event->mmap_mutex))
> > > goto out_put;
> >
> > But when it takes the goto, rb->mmap_count won't decrement anymore..
>
> event->mmap_count is per event, so if we have have race in here,
> 2 threads can go through with each event->mmap_count reaching zero
Maybe I'm missing something.
But as far as I can see, perf_mmap_close() always decremented both
rb->mmap_count and event->mmap_count. But with this change,
it seems not decrement rb->mmap_count when event->mmap_count
doesn't go to zero, right?
Thanks
Namhyung
next prev parent reply other threads:[~2020-09-11 3:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 10:41 [PATCH] perf: Fix race in perf_mmap_close function Jiri Olsa
2020-09-10 13:48 ` Namhyung Kim
2020-09-10 14:47 ` Jiri Olsa
2020-09-11 3:05 ` Namhyung Kim [this message]
2020-09-11 7:49 ` Jiri Olsa
2020-09-14 12:48 ` Namhyung Kim
2020-09-14 20:59 ` Jiri Olsa
2020-09-15 15:35 ` Michael Petlan
2020-09-16 11:53 ` [PATCHv2] " Jiri Olsa
2020-09-16 13:54 ` peterz
2020-09-16 14:38 ` Jiri Olsa
2020-09-16 14:05 ` peterz
2020-10-12 11:45 ` [tip: perf/core] perf/core: Fix race in the perf_mmap_close() function tip-bot2 for Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM9d7ciEAA_3Quo1-q7hU=Te+hBgJ2wYAjbDazXd7yS70HrhPA@mail.gmail.com' \
--to=namhyung@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpetlan@redhat.com \
--cc=wmealing@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.