linux-kernel - Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in v6.1-rc5 kernel in guest

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]

Date:   Thu, 24 Nov 2022 10:00:04 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Marco Elver <elver@...gle.com>
Cc:     Pengfei Xu <pengfei.xu@...el.com>, peter.zijlstra@...el.com,
        linux-kernel@...r.kernel.org, heng.su@...el.com,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in
 v6.1-rc5 kernel in guest

On Thu, Nov 24, 2022 at 09:31:10AM +0100, Marco Elver wrote:
> On Wed, 23 Nov 2022 at 16:05, Peter Zijlstra <peterz@...radead.org> wrote:

> > Subject: perf: Consider OS filter fail
> > From: Peter Zijlstra <peterz@...radead.org>
> > Date: Sat, 19 Nov 2022 10:45:54 +0800
> >
> > Some PMUs (notably the traditional hardware kind) have boundary issues
> > with the OS filter. Specifically, it is possible for
> > perf_event_attr::exclude_kernel=1 events to trigger in-kernel due to
> > SKID or errata.
> >
> > This can upset the sigtrap logic some and trigger the WARN.
> >
> > However, if this invalid sample is the first we must not loose the
> > SIGTRAP, OTOH if it is the second, it must not override the
> > pending_addr with an invalid one.
> >
> > Fixes: ca6c21327c6a ("perf: Fix missing SIGTRAPs")
> > Reported-by: Pengfei Xu <pengfei.xu@...el.com>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > Tested-by: Pengfei Xu <pengfei.xu@...el.com>
> > Link: https://lkml.kernel.org/r/Y3hDYiXwRnJr8RYG@xpf.sh.intel.com
> 
> Thanks, FWIW
> 
> Reviewed-by: Marco Elver <elver@...gle.com>
> 
> One thing I wondered was, if the event fired in the kernel due to
> skid, is the addr always some kernel address, or does this also depend
> on the type of PMU? In any case, we don't even want to risk leaking
> kernel addresses this way, so this looks sane.

That very much depends on the PMU and event. Most events will not fill
out ->addr at all, some memop specific events can, but only when
combined with PERF_SAMPLE_ADDR.

Typically it will then retain the address of the memop. On Intel it's
mostly just PEBS events that can provide the ADDR and they'll have less
such trouble. On AMD we have IBS that can do ADDR but I've forgotten
much about IBS. PowerPC64 also can do ADDR and there I've no clue.