CVE-2026-89503: ring-buffer: Fix subbuf resize race with ring_buffer_alloc_read_page()
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix subbuf resize race with ringbufferallocreadpage()
ringbufferallocreadpage() is racy with ringbuffersubbuforderset, it can allocate a reader page with an outdated order. This isn't a big issue, the user can still re-allocate a new reader page and try again.
However, what is more problematic is if the value of subbuforder changes in the middle of ringbufferallocreadpage(). In that case, bpage->order might not match the actual allocated memory.
Use bpage->order for the allocation to prevent this race.
Affected Software
Event History
Frequently Asked Questions
What condition is required to trigger the race?
The race requires ring_buffer_alloc_read_page() to run while ring_buffer_subbuf_order_set changes the sub-buffer order. If the order changes during allocation, the reader page's recorded order can differ from the memory that was actually allocated.
What is the practical impact if an outdated order is used?
If a reader page is allocated using an outdated order, the user can allocate a new reader page and try again. The more serious case is an order change during allocation, which can leave bpage->order inconsistent with the allocated memory.
How is the issue resolved?
The fix uses bpage->order for the allocation, preventing a mismatch between the page's recorded order and the allocated memory when the sub-buffer order changes concurrently.