lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200306083000.GB248782@krava>
Date:   Fri, 6 Mar 2020 09:30:00 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     He Zhe <zhe.he@...driver.com>
Cc:     Arnaldo Carvalho de Melo <acme@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>, jolsa@...nel.org,
        meyerk@....com, linux-kernel@...r.kernel.org, acme@...nel.org
Subject: Re: [PATCH] perf: Fix crash due to null pointer dereference when
 iterating cpu map

On Fri, Mar 06, 2020 at 03:20:55PM +0800, He Zhe wrote:
> 
> 
> On 3/6/20 3:58 AM, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Mar 05, 2020 at 10:32:06AM -0800, Andi Kleen escreveu:
> >> On Thu, Mar 05, 2020 at 12:27:55PM -0300, Arnaldo Carvalho de Melo wrote:
> >>> Em Thu, Mar 05, 2020 at 06:47:19PM +0800, zhe.he@...driver.com escreveu:
> >>>> From: He Zhe <zhe.he@...driver.com>
> >>>>
> >>>> NULL pointer may be passed to perf_cpu_map__cpu and then cause the
> >>>> following crash.
> >>>>
> >>>> perf ftrace -G start_kernel ls
> >>>> failed to set tracing filters
> >>>> [  208.710716] perf[341]: segfault at 4 ip 00000000567c7c98
> >>>>                sp 00000000ff937ae0 error 4 in perf[56630000+1b2000]
> >>>> [  208.724778] Code: fc ff ff e8 aa 9b 01 00 8d b4 26 00 00 00 00 8d
> >>>>                      76 00 55 89 e5 83 ec 18 65 8b 0d 14 00 00 00 89
> >>>>                      4d f4 31 c9 8b 45 08 8b9
> >>>> Segmentation fault
> >>> I'm not being able to repro this here, what is the tree you are using?
> >> I believe that's the same bug that Jann Horn reported recently for perf trace.
> >> I thought the patch for that went in.
> > Ok, Zhe, that patch is at the end of this message, and it is in:
> >
> > [acme@...e perf]$ git tag --contains cb71f7d43ece3d5a4f400f510c61b2ec7c9ce9a1 | grep ^v
> > v5.6-rc1
> > v5.6-rc2
> > v5.6-rc3
> > v5.6-rc4
> > [acme@...e perf]$
> >
> > Can you try with that?
> 
> Thanks, that does fix the issue I met.
> 
> BTW, my change in perf_cpu_map__cpu can be used as a preventive check
> and the "1"  in perf_cpu_map__cpu should be "0", and assigning a NULL in

I agree, can't see why we had 1 in here.. must be connected to the dummy
map.. could you please double check with all the perf_cpu_map__nr usages
that the 0 will work as expected?

> perf_evlist__exit makes the clearing complete. So are they worth a new patch?

the rest of the hunks looks good as preventive checks

thanks,
jirka

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ