CVE-2026-89771: ring-buffer: Fix subbuf resize race with ring buffer readers
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix subbuf resize race with ring buffer readers
tracebuffer subbufsize is read lockless in ringbufferreadpage() and ringbufferreadstart(), while it can simultaneously be resized with ringbuffersubbuforderset().
Instead of tracebuffer::subbufsize, use bpage::order in ringbufferreadstart() and ringbufferreadpage().
In ringbufferreadstart(), even with resizedisabled, there is still a possibility of a race with a buffer modification. Hold the tracebuffer mutex to synchronise with any pending ring buffer order modification.
tracebuffer::subbufsize is now actually useless, remove it. Also, create accessors rbsubbufcapacity() and rbpagecapacity() which return the actual size available for storing events, while rbsubbufsize() returns the actual subbuf page-size.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the race?
A ring-buffer reader must run concurrently with a ring buffer sub-buffer resize or order modification. The affected read paths are ring_buffer_read_page() and ring_buffer_read_start(), while resizing is performed through ring_buffer_subbuf_order_set().
Does disabling resizing eliminate the issue?
No. The fix notes that ring_buffer_read_start() can still race with a pending buffer modification even when resizing is disabled, so synchronization with the trace_buffer mutex is required.
What code changes address the issue?
The resolved implementation uses bpage::order rather than trace_buffer::subbuf_size in the affected reader paths, and holds the trace_buffer mutex in ring_buffer_read_start() to synchronize order changes. The obsolete trace_buffer::subbuf_size field is removed.