CVE-2026-80876: ring-buffer: Fix event length with forced 8-byte alignment
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix event length with forced 8-byte alignment
When RBFORCE8BYTEALIGNMENT is true, rbcalculateeventlength() reserves the space of event->array[0] for placing the data length and rbupdateevent() stores the data length in event->array[0] accordingly. As a result the whole event length will add extra 4 bytes for sizeof(event.array[0]) unconditionally.
But ringbuffereventlength() only subtracts the sizeof(event->array[0]) for events larger than RBMAXSMALLDATA + sizeof(event->array[0]). As a result, small events on architectures with RBFORCE8BYTEALIGNMENT=true report a data length that is 4 bytes larger than expected.
To fix it, add the RBFORCE8BYTEALIGNMENT as a condition to subtract the size of that length field whenever RBFORCE8BYTEALIGNMENT is true.
This issue is observed in a riscv64 kernel with CONFIGHAVE64BITALIGNEDACCESS set to y, when we run ftrace selftest tracemarkerraw.tc, we get the weird log: for cases where the id is 1..100, the number of data field is 8N, but once id exceeds 100, the number of data field becomes 8N+4: # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 81) ... # a buf: 58 ... (number of data field is 82) ... # 64 buf: 58 ... (number of data field is 813) # 65 buf: 58 ... (number of data field is 813+4)
After applying this change, the number of data field keeps being 8N+4 consistently.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
When CONFIG_HAVE_64BIT_ALIGNED_ACCESS is enabled for ftrace selftests, ensure ring-buffer event length calculation subtracts the length field size only after adding RB_FORCE_8BYTE_ALIGNMENT as a condition; set RB_FORCE_8BYTE_ALIGNMENT=true so rb_calculate_event_length() accounts for forced 8-byte alignment and prevents event->array[0] length reporting as 4 bytes too large (8*N+4 instead of 8*N).
Linux kernel ring-buffer (ftrace/ring_buffer_event_length & rb_calculate_event_length) RB_FORCE_8BYTE_ALIGNMENT = true
Event History
Frequently Asked Questions
Which systems are known to exhibit the incorrect length reporting?
The issue was observed on a riscv64 kernel with CONFIG_HAVE_64BIT_ALIGNED_ACCESS enabled. It applies when RB_FORCE_8BYTE_ALIGNMENT is true, which causes small ring-buffer events to retain an extra 4 bytes in their reported data length.
How can I identify the problem in a running kernel?
Run the ftrace trace_marker_raw.tc selftest and inspect the reported data-field lengths. In the observed behavior, IDs from 1 through 100 have data lengths of 8*N, while IDs above 100 report 8*N+4.
What is the functional impact of the flaw?
Small events can report a data length that is 4 bytes larger than expected. The discrepancy results from reserving space for the length field under forced 8-byte alignment but not subtracting that field for small events when calculating the visible event length.