Re: [RFC PATCH] perf/core: Prevent dereferencing NULL pointer
From: Peter Zijlstra
Date: Mon Feb 10 2025 - 03:37:10 EST
On Mon, Feb 10, 2025 at 04:07:48PM +0800, I Hsin Cheng wrote:
> On Thu, Feb 06, 2025 at 09:05:20AM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 06, 2025 at 03:06:08AM +0800, I Hsin Cheng wrote:
> > > According to coverity scan check, there's possible cases where
> > > "ring_buffer_get()" returns a NULL in "perf_mmap_close".
> >
> > That makes no sense. Having a mmap should pin the buffer.
> >
> > > Use a "BUG_ON()" to check for NULL pointer existence, panic if it does
> > > exist, otherwise it's safe to dereference "rb" and access its members.
> >
> > How the hell is a BUG_ON() any better than a NULL deref?
> >
>
> Hi Peter,
>
> Thanks for the review ! I get it so I think this issue reported by
> coverity scan should be marked as false positive or disgard.
>
> > That makes no sense. Having a mmap should pin the buffer.
>
> I see, so if I understand correctly, the "event" in perf_mmap_close()
> is guaranteed to have available buffer and the buffer's refcount is
> zero, so returning a NULL will never happen right?
Right, the vma / mapping has a refcount on the event, the event has a
refcount on the buffer, and event->mmap_count is incremented, which
makes sure event->rb isn't changd.
So yes, at the time of perf_mmap_close() it *should* be impossible for
ring_buffer_get() to return NULL.