CVE-2026-97617: ring-buffer: Check resize_disabled before publishing the new subbuf order
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Check resizedisabled before publishing the new subbuf order
ringbuffersubbuforderset() stores the new order and only then walks the CPUs, returning -EBUSY if any of them has resizing disabled. A user mapped buffer has resizing disabled, and rbmapvma() reads buffer->subbuforder without buffer->mutex, so an mmap of an already mapped CPU racing the failing order change sizes the mapping with the new order and inserts pages past the sub-buffer into the VMA.
Check the CPUs before storing the new order.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this race to occur?
A buffer must have resizing disabled because it is user mapped, while a sub-buffer order change is attempted and fails with -EBUSY. At the same time, an mmap of an already mapped CPU must race with that failing order change.
What is the observable effect if the race is triggered?
The racing mmap can size its mapping using the newly published sub-buffer order even though the resize operation fails. This can cause pages beyond the sub-buffer to be inserted into the VMA.
How can I determine whether systems have the fix?
Check whether the kernel includes a change that validates CPUs for resize_disabled before storing the new sub-buffer order in ring_buffer_subbuf_order_set(). The provided stable references identify fixes for this issue.