According to coverity scan check, there's possible cases where
"ring_buffer_get()" returns a NULL in "perf_mmap_close".

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.

The scan check report link is:
scan5.scan.coverity.com/#/project-view/63416/10063?selectedIssue=1636067

Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
---
 kernel/events/core.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index bcb09e011e9e..fe83d4754746 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6410,11 +6410,17 @@ static void perf_mmap_close(struct vm_area_struct *vma)
 {
 	struct perf_event *event = vma->vm_file->private_data;
 	struct perf_buffer *rb = ring_buffer_get(event);
-	struct user_struct *mmap_user = rb->mmap_user;
-	int mmap_locked = rb->mmap_locked;
-	unsigned long size = perf_data_size(rb);
+	struct user_struct *mmap_user;
+	int mmap_locked;
+	unsigned long size;
 	bool detach_rest = false;
 
+	BUG_ON(!rb);
+
+	mmap_user = rb->mmap_user;
+	mmap_locked = rb->mmap_locked;
+	size = perf_data_size(rb);
+
 	if (event->pmu->event_unmapped)
 		event->pmu->event_unmapped(event, vma->vm_mm);
 
-- 
2.43.0

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?

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?

Regards,
I Hsin

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.