UBUNTU-CVE-2026-99158: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix false warning in ringbuffermapgetreader() The mmap reader can warn when it catches up with a writer that is still committing events. rbgetreaderpage() returns NULL in this case, but ringbuffermapgetreader() treats that result as an error. The initial rbpercpuempty() check filters out an empty buffer, but it does not guarantee that the next reader page has committed data. Writers do not take readerlock and can advance commitpage before publishing the committed length on the new page. rbgetreaderpage() can swap to that page, catch up with the writer and return NULL. Handle NULL through the existing no-data exit without warning. Remove the caller's readerpage == commitpage check as well, since the reader-page helper already handles that case. The existing metadata update and return path remain in place.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In ring_buffer_map_get_reader(), handle a NULL result from rb_get_reader_page() through the existing no-data exit without warning, and remove the caller-side reader_page == commit_page check because the reader-page helper already handles that case.
Event History
Frequently Asked Questions
Does this issue allow an attacker to gain access or execute code?
The provided information describes a false warning in the Linux kernel ring-buffer mmap reader path during a race with event commits. It does not state any privilege escalation, code execution, information disclosure, or other attacker-controlled impact.
Under what condition can the warning occur?
It can occur when an mmap reader catches up with a writer that is still committing events. A writer may advance commit_page before publishing the committed length on the new page, causing rb_get_reader_page() to return NULL even though the buffer was not initially empty.
Is an empty ring buffer required to trigger the warning?
No. The initial empty-buffer check can pass, but the next reader page may still lack committed data because a concurrent writer has not yet published its committed length.
What behavior does the fix introduce?
The fix handles a NULL result from rb_get_reader_page() through the existing no-data return path rather than treating it as an error and issuing a warning. It also removes a redundant reader_page versus commit_page check in the caller.