Re: [PATCH v5 04/10] ring-buffer: Fix subbuf resize race with ring buffer readers

On Thu, 13 Aug 2026 13:51:42 +0000
[email protected] wrote:

> > +	/*
> > +	 * Only KDB is using GFP_ATOMIC, for the others, lock the buffer to
> > +	 * prevent concurrent resizing.
> > +	 */
> > +	if (gfpflags_allow_blocking(flags))
> > +		mutex_lock(&buffer->mutex);
> >  
> >  	atomic_inc(&cpu_buffer->resize_disabled);
> >  
> > +	if (gfpflags_allow_blocking(flags))
> > +		mutex_unlock(&buffer->mutex);
> > +
> > +	/* Holds the entire event: data and meta data. */
> > +	iter->event_size = rb_page_capacity(READ_ONCE(cpu_buffer->reader_page));  
> 
> [Severity: High]
> Can this cause a use-after-free when called with GFP_ATOMIC?
> 
> If this is called with GFP_ATOMIC, it skips taking buffer->mutex and
> increments resize_disabled without synchronization. If a concurrent
> ring_buffer_subbuf_order_set() evaluated resize_disabled to 0 just before
> this increment, it can proceed to replace and free the reader_page.
> 
> The lockless dereference of bpage->order inside rb_page_capacity() on the
> freed reader_page would then access freed memory. Prior to this patch, it
> read the scalar buffer->subbuf_size which was safe from this use-after-free.

The only caller of this with GFP_ATOMIC is kgdb doing a ftrace dump. It's
in debugging mode and nothing else should be reading the trace buffer while
the system is being debugged by kgdb. If they do, then great, they can keep
the pieces.

-- Steve