linux-kernel - Re: [RFC PATCH] perf/core: Prevent dereferencing NULL pointer

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250210083648.GB10324@noisy.programming.kicks-ass.net>
Date: Mon, 10 Feb 2025 09:36:48 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: I Hsin Cheng <richard120310@...il.com>
Cc: mark.rutland@....com, mingo@...hat.com, acme@...nel.org,
	namhyung@...nel.org, alexander.shishkin@...ux.intel.com,
	jolsa@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
	kan.liang@...ux.intel.com, linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, jserv@...s.ncku.edu.tw,
	shuah@...nel.org
Subject: Re: [RFC PATCH] perf/core: Prevent dereferencing NULL pointer

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.